Chapter 13

Your Price Is a Hypothesis

The Myth of the Correct Number

Once a founder decides the product should cost money, pricing can become an unusually sophisticated form of procrastination. You can research competitors, build spreadsheets, compare monthly and annual plans, calculate cost per user or transaction, ask other founders what they charge, and spend an unreasonable amount of attention deciding whether $49 feels more acceptable than $50. All of this can be useful. None of it reveals a hidden correct price.

I understand why we want one. Pricing feels like the sort of problem that should have an answer. The application exists. The customer gets some amount of value. The software costs something to operate. Competitors charge identifiable amounts. Surely those facts, combined carefully enough, should produce the number.

Technical people are particularly vulnerable to this idea because we are accustomed to problems that improve when the variables become known. Give me infrastructure costs, expected traffic, reliability requirements, and performance constraints, and I can make increasingly defensible engineering decisions. Pricing does not behave quite that cleanly.

You can establish constraints. If serving a customer costs you $80 and you charge $40, arithmetic has already contributed something useful. If the product replaces work costing a company thousands of dollars every month, that matters. If serious alternatives cost several hundred dollars, that matters too. If the buyer can approve $50 personally but needs procurement for $5,000, that matters. Those facts define plausible territory. They still do not contain the correct number.

The problem begins when founders treat price as though it were a property the product already possesses. The application is worth $29, or $99, or $500, and the founder’s job is to calculate accurately enough to uncover it. But a database has a size. An API call has a latency. A server has a cost. A product does not have an objectively measurable price waiting inside it. It has a price somebody is being asked to accept under particular conditions.

That makes price a commercial hypothesis.

Suppose an application saves someone two hours every month. There is no function that converts those two hours into the correct subscription price. The hours could belong to a hobbyist doing something optional, an independent consultant using the time for paid client work, or a senior employee whose delay is holding up a much more expensive process. The software could perform the same task in all three cases while the economic meaning is completely different.

This is where pricing discussions become detached from buying. A founder asks, “Is $99 too much?” and everyone debates the number. The better questions are: too much for whom, for what, compared with what, under what terms, and with what confidence that the product will work? What happens if the buyer does nothing instead? Until those questions have some shape, changing $99 to $79 can create the appearance of precision without much knowledge.

This does not mean the first price should be random. A hypothesis is not a careless guess. It is a belief you can explain and then expose to evidence. If I choose $500, I should have a reason I think $500 is plausible. Perhaps the buyer already spends substantially more dealing with the problem. Perhaps comparable alternatives live in the same range. Perhaps the result has enough economic significance that $500 is a defensible starting point.

That reasoning matters, but it is still reasoning before the decision. The buyer gets a vote.

The first price is not a declaration of universal economic truth. It is the first number you are prepared to defend well enough to test. Instead of asking, What is the correct price?, ask, Why do I currently believe this buyer might accept this price for this offer? The answer may come from costs, competitors, economic value, prospect conversations, or almost no evidence at all. Those situations should not produce the same confidence.

Pricing expertise is not the ability to announce a number with impressive certainty. It is the ability to explain why the number exists, observe what qualified buyers do when they encounter it, and change your conclusion when the evidence deserves it.

Sometimes buyers will reject the price. That does not automatically mean the number was too high. The buyer may not value the outcome enough. They may not trust the seller. The timing may be poor. The offer may be unclear. Price is one possible explanation, and the mistake is assuming it before the evidence isolates it.

The opposite error is possible too. If relevant buyers repeatedly understand the offer, value the result, trust the purchase, and then stop when the same number appears, the price deserves increasingly serious suspicion. That is how a hypothesis should behave. Evidence should be capable of changing it.

I do not treat my first price as a conclusion. I treat it as the first number the market gets to argue with. Research helps choose a reasonable starting point. Buyer behavior begins to tell you whether you were right. To interpret that behavior, though, you have to stop pretending the number exists by itself.

Price Is Contextual

A number is not expensive by itself. It is expensive relative to something.

A $99 purchase can feel absurd for an application that mildly improves a hobby. The same $99 can feel negligible if it prevents a recurring mistake that costs a business thousands of dollars. A $2,500 workflow tool may look outrageously expensive beside a $29 subscription and surprisingly cheap beside the employee time, consultant fees, delays, or errors it replaces. The context changed.

This is why “Would people pay $100 for this?” is incomplete. You need to know which people, what they are buying, how often the problem occurs, what they currently do instead, what happens if they leave it alone, and how much risk they believe they are taking by choosing you. Price lives inside that surrounding system.

A solo creator paying with a personal credit card and a department head paying from an operating budget may evaluate the exact same application differently. One may compare your price with another app subscription. Another may compare it with an employee spending six hours every week doing the work manually. Another may compare it with the cost of getting a decision wrong. Another may have no budget because the problem is inconvenient but not commercially important enough to deserve one.

Frequency changes the calculation too. A tool that saves twenty minutes once a year is different from one that saves twenty minutes every morning. A problem that creates a $500 loss once every five years is economically different from one that creates the same loss every week. Even if the product solves both perfectly, the purchasing environment is different.

Existing alternatives matter for the same reason. If you sell software for managing a process, your competitor is not necessarily another application with a similar feature list. The real alternative may be a spreadsheet, an employee, an agency, an internal script, a weekly meeting, or simply tolerating the problem.

Imagine two products that both cost $500 per month. Product A replaces another application that costs $350 and already works reasonably well. Product B replaces a manual process consuming twenty hours of specialized employee time every month. Product A may need to justify why the additional $150 is worth switching costs and disruption. Product B may be compared with the much larger cost of continuing the current process. They share a price. They do not share a pricing problem.

Even that comparison does not tell you what either product should charge. It only tells you that the buyers are evaluating different trades.

This is where value-based pricing advice can become too neat. It is reasonable to ask what an outcome is economically worth. Ignoring economic value is one of the easiest ways to price a serious business product like a trivial utility. But a product that saves a company $100,000 does not therefore have a mathematically correct price of $10,000, $20,000, or any other convenient fraction. Budgets, alternatives, purchasing authority, uncertainty, and urgency still exist. Economic value helps define the territory. It does not close the sale.

There is also a difference between value and willingness to pay. A founder may save ten hours a month using your product and sincerely believe those hours are valuable while still refusing to pay $200. Another buyer may save only three hours but happily pay $500 because those three hours occur at exactly the wrong moment in an expensive workflow.

The commercial question is not merely, “How much value does the product create?” It is, “How does this buyer experience that value relative to the money, alternatives, constraints, and risk involved in getting it?”

That helps explain why “too expensive” is less precise than it sounds. It can mean the problem is not important enough, the alternative is good enough, the buyer lacks budget authority, the commitment is too large, the expected benefit is too uncertain, or the price really is too high. The point is not to talk yourself out of believing buyers when they object. The point is to understand what the objection contains.

If five qualified buyers reject $1,000, moving to $500 may be a useful test. If the real problem is that they do not believe the product will work, halving the number may solve nothing. If the buyer can spend $750 without approval but anything above it requires procurement, the reduction could materially change the decision. Identical behavior on the surface can come from different commercial constraints.

Price is attached to a particular promise, scope, buyer, commitment, and purchasing environment. Change those things and you may change what the same number means. That does not make pricing hopelessly subjective. It makes it empirical. You form a view about why the purchase should make sense, put an actual price into that context, and see what buyers do.

Once you understand that, copying somebody else’s price becomes much harder to defend.

Packaging Changes the Decision

Price is not only the number. It is also the shape of the purchase.

Two offers can generate the same amount of revenue and still feel different to the buyer. $1,200 per year, $100 per month, $25 per user per month for four users, or a setup fee followed by a smaller subscription can converge arithmetically while creating different commitments and expectations. That is packaging.

Founders often treat packaging as a cosmetic layer added after pricing. First decide what the product costs, then decide whether to put it into Starter, Pro, and Business. Commercially, the order is not that clean. Packaging helps define what the buyer believes they are buying.

A per-seat price says the value scales with the number of people using the product. A usage price says the value scales with consumption. A project fee says the buyer is purchasing a bounded piece of work. A subscription says there is recurring value worth maintaining. An implementation fee says meaningful work occurs before normal use begins. Each structure makes a claim about the product.

Consider a product that helps a team automate a repetitive approval process. If you charge $40 per user and twenty employees need occasional access, the buyer sees an $800 monthly product. Perhaps only two people actively configure the system and the other eighteen touch it for thirty seconds when they approve something. From the seller’s perspective, users are easy to count. From the buyer’s perspective, the pricing can feel like being charged repeatedly for the same workflow.

That reaction does not necessarily mean $800 is too much. The buyer may accept roughly the same amount under a department price or a flat fee for the workflow. If a prospect resists $50 per user but accepts $1,000 per month for the organization, you may have learned where the buyer believes the value exists.

The pricing unit matters because it creates behavior. Suppose an application helps customers process more successful transactions. Charging according to transaction volume may feel natural because use generally rises with value. Now suppose the product reduces the number of incidents a company experiences. Charging per incident would create a strange incentive: the better the product works, the fewer incidents occur, and the less revenue the seller collects. Seat pricing can create similar tension when broad adoption is useful but every additional user increases the bill.

None of this makes usage or seat pricing bad. It means the unit is part of the product experience whether you intend it to be or not.

Commitment changes the decision too. A buyer may reject $12,000 for a year and accept $1,000 for a month even though the monthly rate is identical. They may not know whether the product will work, whether the problem will remain important, or whether the team will adopt it. They may be willing to spend $1,000 to find out and unwilling to commit $12,000 before they know.

A smaller commitment can lower the cost of being wrong, but month-to-month pricing is not universally better. A buyer may prefer annual billing because it simplifies budgeting. A project may require enough implementation work that a short commitment makes no economic sense for the seller. The useful question is not which commitment creates the least resistance. It is which commitment makes sense for the value, risk, and work involved.

Implementation belongs in the package for the same reason. If customers consistently need setup, configuration, migration, training, or hands-on help, pretending that work is free does not make it disappear. Sometimes charging separately makes sense. Other times the separate fee creates unnecessary friction and the work belongs inside a larger contract. There is no universal rule. The package is the hypothesis.

The same applies to tiers. Three tiers are not inherently more sophisticated than one. They are useful when the differences correspond to meaningful differences among buyers, such as more workflows, departments, administrative controls, integrations, or support. They become less useful when they are simply storage bins for features. If a founder has twelve capabilities and mechanically puts four into each tier, the buyer has to decode which collection contains the outcome they actually need.

Good packaging makes the decision legible. The buyer should understand what they are paying for, what causes the price to increase, what commitment is required, and what is included before they have to pay more. Bad packaging forces the buyer to reverse-engineer your business model.

This is also why a pricing test should record more than the headline number. If you move from $99 to $149 while switching from monthly to annual billing, adding onboarding, changing the usage limit, and removing the free trial, you did not test a price. You tested a different purchase. That may be exactly what you needed to do. Just be honest about what changed.

Once you have a package and a real number attached to it, another temptation appears. You can ask people what they think. That sounds like evidence. Often it is much weaker than it looks.

What You Can Actually Test

Founders hear "test the price" and often change only the number. The number is one variable. The transaction has several others, and changing the right one can alter buyer behavior more than moving $79 to $69.

Number. The amount itself: $49, $99, $500, $5,000. This is the obvious variable, and it matters only in relation to the problem, buyer, alternatives, and commitment.

Unit. What the price attaches to: a seat, a workflow, a project, a transaction, a usage amount, an organization, or some other unit the buyer can understand. A pricing unit should track how value is consumed closely enough that the bill feels intelligible.

Scope. What the buyer receives for the amount. A narrow first workflow and a broad platform subscription can contain the same software while creating very different purchase decisions.

Term. Monthly, annual, fixed project, prepaid block, or another period. A longer term can reduce administrative friction and improve predictability, but it also increases commitment and therefore the burden of trust.

Implementation. Whether setup, migration, configuration, or onboarding is included, charged once, or sold as a separate implementation service. A setup fee is not automatically a tax on adoption; when real work happens up front, separating it can make the economics more honest.

Risk and commitment. A paid pilot, a cancellable first month, milestone-based work, or carefully bounded performance-linked pricing can change what the buyer is risking. Use performance-linked structures only when the outcome can be measured cleanly and you control enough of the result to accept the obligation.

These variables interact, which is why pricing experiments become unreadable when you change all of them at once. If you cut the number, change the unit, add implementation, shorten the term, and narrow the scope in the same week, a better conversion rate tells you almost nothing about which decision improved.

A paid pilot deserves special attention because founders often use the word pilot to describe a discounted subscription. A useful paid pilot buys a defined evaluation: a bounded problem, a real price, success criteria both sides understand, and a next commercial step if the result appears. It tests willingness to commit without pretending the buyer is ready for the entire relationship.

The same discipline applies to setup-fee-plus-recurring pricing. If the first month contains real implementation work and later months contain recurring software value, separating those economics may produce a clearer proposition than forcing both into one subscription number. Conversely, if setup is nearly automatic, inventing a fee to make the offer look more substantial is just packaging theater.

The practical rule is simple: name the variable you are testing before you change the transaction. Price is a hypothesis, but the hypothesis should say more than "cheaper will convert better." It should say what you believe the buyer is reacting to and what behavior would make you change your mind.

Ask Behavior, Not Opinion

“What would you pay for this?” sounds direct. It sounds commercial. It feels much better than asking whether someone likes the idea.

It is still an opinion question.

The person answering does not have to give up money, request approval, choose among alternatives, or defend the purchase to anyone. They can be generous, polite, optimistic, curious, or completely detached from what they would do in a real buying situation. A number spoken in conversation is not the same thing as a price accepted in a purchase.

Suppose a prospect says they would “probably pay $100 a month.” You record $100 as evidence. Three weeks later, you send them a link for $79 and nothing happens. That does not necessarily mean they lied. They were imagining a future decision under conditions that did not yet exist. When the real decision appeared, so did the other questions: Do I need this now? Will I actually use it? Do I trust it? Is what I already have good enough? Do I want another subscription?

That is the difference between pricing opinion and pricing behavior. The first tells you how someone thinks about the number. The second tells you what happens when the number becomes part of an actual decision. Both can be useful. They are not equally strong.

If a qualified buyer says, “There is no chance I would pay $500 for this,” that is information. You should not ignore it. But you should resist turning one verbal reaction into a pricing law. Maybe $500 truly exceeds what the market will bear. Maybe the buyer is wrong for the product. Maybe the offer was poorly explained. Maybe the purchase only makes sense for companies dealing with the problem at a larger scale.

You learn more when the price is attached to a concrete next step. Instead of asking whether someone would pay $500, present the actual offer: what it does, what is included, the commitment, and the price. Then ask whether they want to proceed. Now the buyer has to decide.

A no at a real decision point is often more useful than enthusiastic speculation because it creates something you can investigate. What stopped the purchase? The answer might be price. But now you are examining a real refusal rather than asking someone to predict imaginary future behavior.

There is a useful difference between “That seems expensive” and “I would buy this if it were $300 instead of $500.” The second statement identifies a specific tradeoff. It becomes stronger if the buyer is willing to act on it: “If we can do $300 for the first three months, I’m ready to start.” Now you are negotiating a purchase rather than collecting taste.

This is where the Commitment Evidence Ladder becomes useful again. Accepting a price is stronger than expressing interest because the buyer has moved closer to a consequential decision. Paying is stronger still. Pricing research should move in that direction whenever possible. Conversations should help you reach a decision rather than replace one.

There are still good questions to ask before presenting a number. Ask what the buyer does today, what that costs, who controls the budget, whether purchases like this require approval, whether the problem already has money attached to it, and what alternatives are being considered. Those questions help you understand the economic environment without asking the buyer to design your pricing.

Customers are usually better at describing their constraints than prescribing your business model. “Anything over $1,000 has to go through procurement” is useful. “You should charge $49.99 because that feels like the right SaaS price” is considerably less useful. One describes how purchasing works. The other is amateur pricing advice.

Founders invite that advice partly because asking for opinions feels safer than asking for money. A conversation about price can remain collaborative. A purchase request introduces the possibility of rejection. That is uncomfortable. It is also the point.

Early on, the evidence may come from only a handful of serious sales conversations. That is enough to start learning if you present the offer consistently, note where buyers hesitate, distinguish objections to the number from objections to the product or commitment, and watch whether lower prices change the decision or merely change the explanation for saying no.

Most importantly, record what people do. A buyer who says $500 sounds reasonable and disappears has given you weaker evidence than a buyer who complains that $500 is expensive and then pays it. Markets rarely provide the clean sentence founders want. People say something is expensive and purchase it anyway. They say something is affordable and postpone it indefinitely.

Opinions help you form hypotheses. Decisions test them. A price becomes useful evidence only when the buyer has to accept or reject it under real terms.