Chapter 8

“I’d Use This” Is Not Demand

Why Hypothetical Intent Is Cheap

“I’d use this” is one of the nicest sentences a builder can hear, particularly after spending months wondering whether anyone outside the development team understands why the product exists. The person sees the problem, understands what the application does, and can picture themselves using it. Maybe they ask when it will be available or tell you to send them a link when you launch. It feels like demand because the distance between interest and purchase suddenly seems very small.

It may eventually become demand, but at the moment the sentence is spoken, something important is missing: nothing has been given up. Suppose you have done the work from the previous chapter well. You are talking with ten plausible buyers who really experience the problem, whose current workaround consumes time or money, and who have a credible reason to care. Eight say they would use the product, six describe the existing process as terrible, four ask when you are launching, and one says, “Seriously, send this to me as soon as it is ready.” Those reactions are useful, but none yet tells you what happens when your product has to compete with something the buyer must surrender.

That is the weakness of hypothetical intent. The imagined version of the decision is unusually cooperative. The product works as described, the integration goes smoothly, the data imports correctly, the team adopts it, and nobody objects. The price may not have appeared yet, or it exists as an abstract future detail. The buyer has not had to cancel another tool, explain the change to a manager, find time for setup, retrieve a company credit card, or disturb the spreadsheet someone built three years ago and now regards as part of the local infrastructure. The imagined product also has an excellent reliability record because it has never had an outage.

Actual buying decisions are made under constraint. Money, time, attention, organizational patience, existing habits, and competing priorities all enter the decision. A team can genuinely prefer your product and still decide that this quarter is not the quarter to introduce another system. A founder can collect dozens of encouraging interviews, waitlist signups, feature suggestions, and “keep me posted” messages without ever forcing the product to compete with one of those constraints.

The easiest way to see the difference is to introduce even a small cost. If a prospect says, “I’d absolutely use this,” ask whether they will spend thirty minutes next Tuesday evaluating the actual product with one of their real workflows. You have not asked for money or a contract. You have merely put a calendar in the decision. Tuesday at 2:00 p.m. now competes with whatever else happens on Tuesday at 2:00 p.m., and the buyer has to decide whether the product deserves that piece of the day.

If eight people say they would use the product but only one will schedule the evaluation, I do not throw away the eight positive reactions. They still tell me something. I simply stop treating those reactions and that one appointment as equivalent evidence. A hypothetical yes tells you that the product survives imagination; the business needs to know whether it survives competition with money, time, inertia, risk, existing tools, internal priorities, and the inconvenience of changing what the buyer already does.

That does not make the original interest fake. It means the statement is worth less than founders are often tempted to make it worth. To understand why, it helps to separate sincerity from predictive strength.

Commitment Creates Information

A statement becomes more useful when making it costs something. The cost does not have to be money. A buyer can spend time, inconvenience, organizational attention, reputation, flexibility, or the opportunity to do something else. Once that happens, the person is no longer describing a future from the comfort of having sacrificed nothing. They are making room for the product in the world they actually operate in.

Imagine two prospects who both say, “I really want to try this.” The first says it at the end of a demo and disappears. The second schedules an evaluation for Thursday, invites the person who owns the current workflow, exports a sample of real data, and sends three questions about whether the product can handle it. The sentence was the same, but the second prospect has started allocating resources. The possibility now occupies calendar time, involves another person, and creates a small amount of inconvenience if the evaluation goes nowhere.

I think of commitment as a way of making the buyer’s internal competition visible. Before commitment, the product is mostly competing with imagination. Once the buyer takes action, it competes with the actual calendar, budget, habits, coworkers, approval process, and alternatives. Those competitors are considerably less polite. A prospect may describe a problem as urgent and still refuse to make time for an evaluation, or may enthusiastically test the product until the price appears. Another may react with less excitement but quietly bring in the budget owner and ask what is required to begin next month. I care more about the behavior surrounding the reaction than the emotional intensity of the reaction itself.

The purpose is not to force everyone to prove themselves. Different products require different commitments at different stages. Asking a consumer evaluating a simple utility to assemble a committee and sign a letter of intent would be absurd, just as expecting an enterprise buyer to swipe a credit card after a ten-minute demo of infrastructure touching regulated data would be absurd. The commitment has to fit the decision. What matters is that the next action requires enough from the buyer to separate casual interest from a more serious intention.

Software builders already understand the principle in another form. A test environment can tell you a great deal, but production introduces constraints the test did not contain: real load, strange inputs, stale credentials, unexpected dependencies, and eventually somebody pasting an entire email thread into a field labeled First Name. The test was not fake. Production simply made the system confront more reality. Buyer commitment does something similar. “I’d use this” is a useful test environment; commitment introduces production conditions.

As the decision becomes more real, different constraints enter. The buyer may first spend time, then involve coworkers, then confront the price, implementation burden, or approval process. Eventually money may move, and later the product may have to justify another payment after the buyer has experienced it. Each stage tells you something the previous stage could not because the buyer is allocating something scarcer than an opinion.

This is why a pipeline that labels everyone “interested” can become misleading. One person may like the idea, another may have scheduled a demo, another may be evaluating with real data, another may have accepted the price, and another may be preparing a pilot. Those are not five versions of the same signal. They represent a progression in what the buyer has actually demonstrated, which means we need a scale for distinguishing them.

The Commitment Evidence Ladder

The progression I use is the Commitment Evidence Ladder:

expressed pain → agrees to evaluate → accepts a price → dated pilot or conditional commitment → pays → renews

The ladder is not a universal sales process. Consumer software may collapse several rungs into a single screen, while an enterprise purchase may contain five approval steps between two of them. It is an evidence scale. Its purpose is to answer a narrower question: What has this buyer actually demonstrated so far? At each rung, the buyer has allowed more of the real decision to enter, which gives the founder less room to promote hope into evidence.

Expressed pain

Statements such as “the current process takes forever,” “we hate doing this manually,” or “we need a better way” can matter, especially when the previous chapter’s economic conditions are present. A team spending ten hours every week compensating for a broken workflow deserves more attention than someone complaining casually about a minor inconvenience. Even meaningful pain, however, is evidence about the problem. It does not yet show that the buyer will choose your product.

That distinction is easy to lose because founders naturally want the problem and the solution to remain in the same sentence. “They spend twenty hours a week on this, so they need our app” sounds logical, but the twenty hours tell you only that the problem has weight. They do not tell you how the buyer will respond to your product, implementation burden, credibility, alternatives, timing, or price. Expressed pain earns investigation, not a revenue forecast.

Agrees to evaluate

The next rung appears when the buyer gives the product a serious opportunity to compete. They may schedule the demonstration, create the trial account, bring real data, test the workflow, or involve a colleague who matters to the decision. Evaluation consumes resources, which makes it stronger evidence than verbal interest. A prospect who spends forty-five minutes on Tuesday has spent forty-five minutes they cannot spend elsewhere, and the cost rises if they prepare data or coordinate coworkers.

An evaluation is still not a purchase. Some people enjoy trying software, some companies routinely examine tools they never adopt, and a free trial can attract curiosity. What has changed is more modest and more useful: the buyer has moved from “that sounds useful” to “this may be useful enough to investigate.” The conclusion should rise only as far as the behavior supports it.

Accepts a price

Price changes the conversation even before payment occurs. A prospect may tell you the product solves an important problem, evaluate it seriously, and like the workflow. Then you tell them it costs $500 a month. If the conversation ends immediately, you have learned something that no amount of praise before the number could reveal. If they continue discussing implementation, timing, approval, or terms, you have learned something different.

Accepting a price does not mean the buyer has paid. It means the number itself did not destroy the commercial proposition. Before the price appears, the product can be mentally priced at whatever amount makes enthusiasm convenient. A buyer who says, “Yes, $500 a month is within range if the evaluation works,” has therefore supplied stronger evidence than someone who says, “I could definitely see paying for this.” The first statement has encountered a number. The second has encountered grammar.

Dated pilot or conditional commitment

This is where interest begins to acquire edges. “We should try this sometime” leaves the future almost infinitely movable. “If the integration is ready by October 1, we’ll run the product with the operations team for thirty days at the quoted pilot price” contains a condition, a date, an action, and perhaps an owner and a price. The buyer has made explicit what they currently believe stands between the present situation and action.

That commitment can still disappear. Priorities change, budgets freeze, people leave, and the supposedly final requirement occasionally introduces us to its close relative, the new final requirement. Still, a specific condition tied to specific behavior is substantially stronger than “keep me posted” because it gives the founder something that can actually be tested.

Pays

Payment changes the commercial experiment sharply. Until money moves, willingness to pay is still partly inferred. Once it moves, at least one buyer under one set of conditions decided that keeping the money was less attractive than acquiring what you offered. That deserves considerably more weight than a signup, compliment, demo, feature request, or free trial.

It also deserves restraint. One payment does not prove that a market exists at scale, that the price is optimal, that the buyer represents the segment you expected, or that the acquisition path will repeat. It does establish one thing none of the lower rungs can establish: somebody actually paid. That is a different class of evidence, not the end of the analysis.

Renews

Renewal asks a different question again. The first purchase is made partly on expectation; renewal occurs after the buyer has experienced onboarding, limitations, support, workflow fit, and whatever value the product actually delivered. A customer who chooses to continue is therefore giving you information the first-time buyer could not.

Renewal is not perfect evidence. Customers can stay because switching is painful, because the charge is easy to overlook, or because the alternative is worse. They can also leave despite receiving value because the underlying need disappears or the company changes direction. Retention deserves deeper treatment later in the book. For this ladder, the important point is simply that continuing after experience tells you something stronger than buying on promise.

The ladder does not predict every customer’s future, and it does not imply that all buyers must climb in perfect order. Its value is more basic. It prevents six different situations from being compressed into the same word, interest. As the buyer gives up more freedom and the decision encounters more reality, the evidence becomes harder to overinterpret.

Conditional Commitments

Conditional commitments deserve special attention because early buying decisions are often not ready for a clean yes or no. A prospect may need one integration before a meaningful evaluation, a company may require security approval, or a team may want to test the product on its own data before paying. In those situations, demanding payment immediately can produce little information, but accepting “keep me posted” produces little information too. A conditional commitment sits between them.

The useful structure is: If X becomes true, under these conditions, by this date, I will do Y. Compare “If you add Salesforce, we’d be interested” with “If the Salesforce integration is working by October 15 and the product performs as demonstrated, we’ll begin a thirty-day paid pilot at $1,000.” The second statement is not a completed sale, but it attaches behavior to the requested condition. That makes the request much more informative.

The integration example from Chapter 4 illustrates the difference. One prospect wanted a substantial integration but would not say that delivering it would cause them to proceed. Later prospects asking for the same capability gave stronger commitments: one agreed to a paid implementation pilot contingent on the integration working, while another agreed that completion would satisfy the remaining technical requirement in its evaluation. The feature request was similar in each case. The commercial evidence surrounding it was not.

This distinction helps separate an obstacle from a preference. Buyers are excellent at identifying things they would like improved: another integration, SSO, mobile support, a particular export, security certification, different billing, or support for an edge-case workflow. Founders then tend to complete the sentence on the buyer’s behalf. “We would need SSO” quietly becomes “If you build SSO, we will buy.” Sometimes that is true. Sometimes SSO is merely the most visible objection at the current stage, and satisfying it reveals another requirement that neither party had reached yet.

A useful conditional commitment therefore needs enough specificity to expose the current theory of the decision. “If you support our identity provider, we’ll move forward” sounds promising until you ask what move forward means. Does the buyer mean begin technical evaluation, start a free pilot, submit the vendor for procurement, run a paid pilot, or purchase the annual plan? The clearer the condition and resulting behavior, the more useful the commitment becomes. A date helps too because it reveals whether the issue matters enough to occupy a real place on the calendar.

This can materially change engineering priorities. Suppose three prospects request the same integration. One says it would make the product more useful, another agrees to place the product into a December evaluation if the integration exists by November 1, and a third agrees to begin the paid pilot already discussed if the integration passes testing by that date. The underlying product request may be identical, but the commercial evidence is progressively stronger. When engineering capacity is scarce, that difference matters.

AI-assisted development makes this discipline even more important because reacting to requests has become so easy. A prospect can mention a feature in the morning and a founder may be able to produce a convincing version by afternoon. Speed can be genuine customer responsiveness, but it can also prevent you from learning why you are building. Even cheap features accumulate, and every untested request trains the company to respond to preference rather than commercial consequence. The useful question is not simply whether you can build the feature. It is what the buyer is prepared to do if you do.

The commitment should match the person’s authority. An operations manager who cannot approve a $50,000 contract cannot give you a meaningful promise to buy one, but they may be able to commit to introducing the VP, sponsoring an internal pilot, or submitting the product for vendor review if a technical test succeeds. Conditional commitments are diagnostic tools, not closing theater. They make the buyer’s current theory explicit and give the founder a way to test it before investing heavily in turning a maybe into a project.

Use the Ladder to Design Tests

The Commitment Evidence Ladder becomes useful when it changes what you do next. Otherwise, it is just a respectable-looking sequence of arrows, and business books already contain enough arrows.

Start with the people you currently describe as leads, prospects, users, potential customers, beta participants, or interested companies. Those labels are convenient, but they often hide important differences in behavior. One person may have described the problem as expensive, another scheduled a demonstration, another tested the product with real data, another continued after seeing the price, and another agreed to begin a pilot if a specific requirement is satisfied. Calling all of them “interested prospects” throws away most of the useful information.

Put them on the ladder instead: expressed pain → agrees to evaluate → accepts a price → dated pilot or conditional commitment → pays → renews. Once you know where someone is, ask what the next reasonable commitment would be for that particular buyer. Someone who has only acknowledged a serious problem may need a real evaluation, not an annual contract. If the evaluation succeeded but the price has never appeared, make the price real. If the buyer has accepted the price but remains in an indefinite state of pleasant conversation, clarify what concrete action would move the decision forward. If a feature supposedly blocks progress, tie it to a conditional commitment rather than assuming the feature will unlock a sale.

Suppose six qualified prospects for a workflow application all describe the existing process as expensive and frustrating. “Six highly interested prospects” sounds encouraging, but it tells you very little. A more useful record is that six described meaningful economic pain, four agreed to evaluate, three completed the evaluation, two continued after seeing the $500 monthly price, one agreed to begin a paid pilot if a required integration passed testing, and none had paid yet. That version is less emotionally convenient, but it shows exactly where the evidence becomes thinner.

The description should change the next experiment. Another survey asking whether the problem is painful would add little because you already have stronger evidence than that. Adding fifty more names to the top of the pipeline may also accomplish very little if the buyers farthest along have not yet faced the next meaningful decision. The useful work is to understand whether those buyers will make the next commitment and what happens when they are asked to do so.

This is one reason the ladder can feel uncomfortable: the number of people tends to shrink as the evidence gets stronger. Twenty people may willingly discuss a problem, eight may evaluate, three may seriously consider the price, and one may proceed to a pilot. The apparent opportunity becomes smaller as the experiment becomes more realistic. That is not a defect in the method. Commercial testing is supposed to discover which assumptions survive when buyers have to do something, not preserve the largest possible number of people under the heading potential customer.

I would rather know that one out of twenty qualified prospects reached a serious purchase decision than describe all twenty as interested and spend the next three months wondering why the interest has such unusual difficulty appearing in the bank account. That preference changes how I design tests. Before a conversation, campaign, pilot, or product change, I want to know what behavior would count as stronger evidence than the behavior I already have.

Suppose you believe accounting firms have a costly problem collecting documents from clients. Once you have credible evidence of that problem, continuing to ask whether accountants dislike chasing paperwork does not move the commercial question very far. The next test might be whether firms experiencing the problem will evaluate your workflow against the process they use today. If enough do, expose the offer and price. If the proposition survives that, see whether a qualified buyer will commit to a pilot under defined conditions. Eventually the appropriate test becomes payment.

Each experiment should make the decision more real than the experiment before it. Without that discipline, founders can spend months repeatedly confirming the same attractive fact: people dislike the problem, people find the solution interesting, and people have ideas for making the solution even better. Activity continues, conversations accumulate, and the product keeps changing while the most important commercial uncertainty remains untouched.

The next question is often avoided because it is less comfortable than the previous one. Showing the price is less comfortable than hearing praise after a demo. Asking for a dated pilot is less comfortable than discussing what a pilot might look like someday. Asking for payment is less comfortable than collecting another round of feedback. The ladder reveals when research has stopped advancing and become a way of circling an answer the founder is reluctant to request.

It is equally useful when buyers stop moving. If qualified prospects repeatedly acknowledge a serious problem but will not evaluate, investigate that boundary. If they evaluate successfully but withdraw when the price becomes concrete, investigate there. If they accept the price but resist putting a pilot on the calendar, the obstacle is different again. The discipline is to record the last commitment that actually occurred rather than promoting the buyer to the commitment you hope comes next.

That is why I think of the Commitment Evidence Ladder less as a sales funnel than as a restraint on founder interpretation. It keeps “they need this” from gradually becoming “they want our product,” keeps product interest from becoming assumed willingness to pay, and keeps one payment from becoming proof of a repeatable business before repeatability exists. Each stronger conclusion may eventually become true, but the missing evidence has to come from buyer behavior rather than from the founder completing the story on the buyer’s behalf.

This is calibration, not cynicism. Someone who says, “I’d use this,” may eventually become your best customer. The useful response is not to distrust the statement but to understand what it currently tells you, then create an appropriate opportunity for the buyer to demonstrate something stronger. If they make the next commitment, your confidence should change. If they do not, your understanding of the opportunity should change instead. Either result improves the commercial picture.

There is, however, one problem the ladder cannot solve. You can identify a buyer with severe economic pain who is willing to evaluate, comfortable with the price, prepared to pilot, and entirely capable of becoming an excellent customer. That still does not help much if finding another buyer like them depends on luck, a personal introduction you cannot reproduce, access to an organization you cannot obtain, or a buying process you have no credible way to enter.

A buyer can therefore look nearly perfect on paper and still be a poor first market. Commitment tells you how much evidence a particular buyer has given you. The next question is whether you can reliably get close enough to similar buyers to collect that evidence again.