Pricing Hypothesis Sheet

A Price Creates a Product

A founder can type an amount onto a landing page in an afternoon. The difficult work begins when a customer says yes. Someone must know what was bought, collect the money, grant the right access, deliver the promised result, answer questions, recognize overuse, handle cancellation, and keep a reliable record of the agreement.

This is why an early price is more than a monetization choice. It is a claim about value and a proposal for operating the product. The next pricing test should reveal whether a specific buyer will exchange money for a specific outcome without forcing one founder to build the machinery of a mature business first.

Use this sheet before a paid pilot, preorder, invoice test, pricing-page test, early subscription, or usage-based experiment. Return to it when prospects praise the product but avoid payment, when each sale creates a different promise, or when tiers, trials, seats, credits, discounts, and metering begin to look like progress.

Bring the product thesis, positioning-to-scope map, buyer and user evidence, notes about the current alternative, delivery and support costs, and the simplest trustworthy way to collect payment. If the buyer, value, or workflow exists only in the founder’s imagination, a detailed price will not make it less imaginary.

Write the Exchange in One Sentence

Complete this sentence before choosing billing software:

[Buyer] will pay [amount] [once or per customer-visible unit] for [bounded entitlement] because [valuable outcome] improves on [current alternative]. We can test this through [payment and delivery method] and will reconsider if [observed stop condition].

Every phrase must survive a customer conversation. “Teams will pay for automation” has no buyer, exchange, or boundary. “Operations managers will pay $600 for one assisted review of up to 500 job records, delivered within two business days, because it shortens the repair work before a recurring client update” can be accepted, refused, or corrected. It also exposes the work hidden behind the price.

The amount is a test, not a valuation of the product’s ultimate worth. The unit and entitlement are hypotheses too. A refusal may challenge the outcome, the package, the buyer, the trust required, or the timing of the offer. Record which one the customer actually rejected.

Build the Sheet from Value to Operations

Keep one working page under the sentence. Use the following headings in order.

Buyer and purchase moment

Name the person who can commit money, the person who receives the value, and the event that makes a purchase timely. If approval passes through another role, record the path rather than treating the user as the buyer. Add the customer’s own description of the problem and any evidence that budget already moves around it.

Current alternative and its full cost

Describe what happens without the offer. Include tools and services, but also staff time, delay, rework, lost revenue, mistakes, and risk when the customer has supplied credible evidence for them. Do not turn an unverified estimate of “time saved” into a confident return-on-investment claim. The alternative also has advantages—familiarity, flexibility, control, or bundled service—that the paid offer may need to preserve.

Outcome, unit, and first offer

Name the result worth buying, then choose a unit the customer can see: a review cycle, location, project, account, transaction, seat, or another natural unit of work. State the amount, whether it recurs, and exactly what the first offer is: a paid pilot, fixed-scope service, deposit, subscription, or usage block.

Prefer a unit that follows the customer’s value over one that follows an internal implementation detail. “AI credits” may mirror compute cost while leaving the customer unable to predict a bill or recognize what was purchased. A simple unit is not automatically a good unit, however. Per-seat pricing can punish broad adoption, and per-transaction pricing can create metering and dispute work before it reflects value.

Entitlement and delivery boundary

Write what the payment includes: accepted inputs, output, volume, turnaround, access period, onboarding, support, and any human work. Then write what it excludes. A bounded entitlement lets the customer judge the offer and prevents an improvised courtesy from becoming a permanent feature of every account.

Minimum money and access system

Trace one successful purchase from agreement to delivery. Record how the founder will quote or display the terms, collect payment, issue a receipt or invoice as appropriate, grant access, recognize the customer’s entitlement, track fulfillment, and preserve the commercial record. Add who can correct a payment or access mistake.

Manual operation is often the honest first system. It still needs explicit terms and reliable records. A payment link plus an entitlement ledger may teach more than subscription code while the package is changing. Automation becomes useful when repeated purchases have stabilized the unit, terms, and exceptions—not when the founder is still discovering them.

Support, cancellation, and exception cost

State the support promise, response boundary, cancellation or refund rule, and what happens when usage exceeds the package. List the exceptions already visible: failed payments, invoice requests, tax or procurement questions, account changes, partial delivery, disputes, and customers asking for a custom package. The founder does not need to automate every case, but the offer must not depend on pretending they will never occur.

Evidence and next decision

Decide what the test must reveal and what observation will change the thesis. Record offers made, buyer role, amount and terms presented, response, stated objection, payment behavior, delivery effort, support effort, and requested exceptions. Choose a date or a small number of qualified offers for review.

Write separate actions for distinct evidence. If the right buyers understand the outcome but reject the amount, test price or package. If they dispute the unit, change the unit. If users want the result but the supposed buyer cannot fund it, revisit the buying path. If customers pay but every delivery consumes unsustainable founder time, narrow the entitlement or change the delivery system before seeking more demand.

Modeled Sheet: One Paid Review Cycle

This modeled example continues the fictional field-service product from the preceding templates. It demonstrates the reasoning; it is not market evidence.

An operations manager is both user and proposed buyer when incomplete job records threaten a recurring client update. The current alternative is a scheduling export, technician messages, calls, and the manager’s own reconstruction work. That process preserves judgment and access to source records, so the offer must preserve both.

The first hypothesis is a $600 assisted review cycle for one export of up to 500 job records. The founder maps the agreed columns, runs deterministic completeness checks, returns an editable list of source-linked flags within two business days, and joins one 30-minute handoff. The manager decides which flags matter and remains responsible for the client update. Native integrations, generated narrative, continuous monitoring, and record repair are outside the offer.

The minimum commercial system is a written order describing the input, limit, output, delivery window, data handling, support boundary, and cancellation terms; an invoice or payment link; and a ledger connecting payment status to the promised review. No subscription, seat administration, usage meter, or tier engine is needed to learn whether the review cycle is a useful buying unit.

The test should record whether qualified operations managers accept the cycle, compare it with staff effort or another service, ask for a different unit, or require an integration before paying. It should also record founder hours and exceptions. Payment accompanied by bespoke mapping, daily calls, and unbounded interpretation is evidence of demand for a service, but not yet evidence that this package can become a one-person product.

Read the Result without Protecting the Price

Avoiding the money conversation protects the idea from useful evidence. So does copying a mature competitor’s tiers: those tiers may carry sales teams, procurement support, integrations, market trust, and billing systems that do not belong to the first offer. Underpricing can hide the same uncertainty by purchasing politeness and support-heavy customers instead of testing commercial weight.

Run the test when the buyer, purchase moment, outcome, unit, amount, entitlement, payment path, support boundary, exit terms, and stop condition can be stated without improvisation. Keep the system manual while those terms are moving. Build billing and entitlement automation after repeated behavior shows which agreement deserves to become software.