Pricing and packaging

# Pricing and packaging

## Goal

Turn the current ICP, market audit, and positioning into a monetization system: the unit being sold, the price the product can defend, the packages a beachhead buyer can choose without confusion, and the discount or services exceptions that will not destroy the unit economics.

Pricing is a claim about value captured. Packaging is a claim about which jobs are in and out of the offer. Neither is a vanity tier list copied from another SaaS site.

Complete the analysis autonomously. Do not stop to ask clarifying questions. When evidence is missing, make the narrowest assumption that permits a usable offer or an explicit `HOLD`, label it, define the fastest observable test, and state what decision changes if it is false.

Do not modify application code. Do not contact buyers. Do not publish a price the current evidence ceiling cannot support.

## Prerequisites

Read, in order:

* all applicable `AGENTS.md` files and repository guidance
* the latest ICP Markdown and YAML pair
* `docs/gtm/icp-changelog.md`
* `docs/gtm/market.md` and `docs/gtm/market.yaml` when they exist
* `docs/gtm/positioning.md` and `docs/gtm/positioning.yaml` when they exist
* billing, pricing pages, invoices, discounts, refunds, credits, and packaging copy
* delivery-cost, infrastructure, model, support, and founder-labor records
* any existing `docs/gtm/pricing.md`, `docs/gtm/pricing.yaml`, and `docs/gtm/pricing-changelog.md`

If no ICP exists, stop and say so. Do not invent a price for an undescribed customer.

If positioning exists and its decision is `HOLD` or `REVISIT ICP`, do not invent a prettier offer to rescue it. Price the inherited position, or return `HOLD`.

If the market decision is `DO NOT PURSUE`, return `HOLD` or `REVISIT OFFER`. A price cannot create a market the audit rejected.

### Evidence ceiling

* `v0.1`: hypothesized price only. Ground it in cost to serve, the value metric, and named alternatives. Label it `ASSUMED`. No “customers will pay.”
* `v0.2`: interview evidence of current expenditure, budget owner, and failed purchases may bound a range. Stated willingness to pay is not payment.
* `v0.3`: observed pilot prices, concessions, refunds, and refused price points are allowed with sample limits.
* `v1.0`: retained revenue, expansion, and unit economics constrain the sustainable price.

Competitor prices prove what they ask, not what this beachhead will pay. Invoice totals prove what was charged, not that the package was understood.

## Evidence standard

Label every material claim `REPOSITORY-PROVEN`, `MARKET-OBSERVED`, `DERIVED`, `INFERRED`, `ASSUMED`, `UNKNOWN`, or `CONTRADICTED`.

Separate four money ideas and never add them together:

* customer loss or cost of the status quo
* addressable expenditure already flowing to alternatives
* willingness to pay
* vendor revenue this product can capture

## Step 1: Inherit the commercial facts

Extract, do not rewrite as marketing:

* beachhead, buyer, champion, user
* job, trigger, value metric, initial use case
* named alternative and budget displaced
* retrieval noun and exclusion line
* market ACV range or pricing basis
* cost to acquire a guess, cost to implement, cost to support, founder hours
* current public price, if any

Produce an inheritance table: field, value, source, evidence label, pricing implication.

## Step 2: Choose the pricing unit

Pick the unit that matches how value is created and how the buyer already budgets:

* account
* seat
* workflow or job instance
* usage
* outcome
* project or implementation
* hybrid only if the secondary meter is observable and billable without argument

Reject a unit the product cannot measure, the buyer cannot procure, or the team cannot invoice without founder translation.

Record the value metric, the billing meter, the collection cadence, and what happens when usage is bursty or idle.

## Step 3: Bound the price from evidence, not from taste

Build a low / base / high range from:

* cost to serve, including founder labor
* status-quo expenditure and alternative prices
* observed invoices, pilots, and refused prices
* the value metric times a conservative capture rate

Show the formula. If a bound is missing, say `UNKNOWN` and narrow the external claim.

A price below fully loaded cost is a subsidy. Name it as a subsidy, with a time limit, or do not offer it.

A price above any observed or inferred budget is a wish. Keep it internal.

## Step 4: Package by job, not by feature count

Create the smallest set of packages that a beachhead buyer can tell apart in one reading.

Each package must state:

* who it is for
* the job it completes
* what is included
* what is excluded
* the pricing unit and price or range
* implementation burden
* the segment it should repel

Rules:

* Do not create Good / Better / Best unless the jobs are actually different.
* Do not hide the useful product behind an enterprise SKU the beachhead cannot buy.
* Do not include YELLOW or RED work in the default package.
* Do not sell custom development as if it were software margin.
* One recommended package for the beachhead. Other packages are exceptions with a reason.

## Step 5: Write the commercial guardrails

Define:

* list price versus exception price
* who can discount, by how much, and what must be true
* when services, onboarding, or founder time are billed separately
* refund, pause, and cancellation terms the product can actually honor
* expansion and contraction rules
* the first paid offer if the current motion is still a pilot

If the only way a deal closes is an undocumented exception, the price is not the price.

## Step 6: Desk-test, then design the live tests

Desk tests:

1. **Inheritance.** The offer sells the positioned job to the beachhead, not a different product.
2. **Unit.** The meter is measurable and procurable.
3. **Floor.** Fully loaded cost is below the recommended price, or the subsidy is explicit and dated.
4. **Ceiling.** The price does not exceed any evidence-backed budget bound without a `HOLD`.
5. **Exclusion.** A RED or YELLOW buyer cannot buy their way into a bad-fit package by default.
6. **Comprehension.** A new hire can quote the offer from the playbook.
7. **Evidence.** No public price claim sits above the ceiling.

Then design, do not run: one price or package test with confirmation and falsification thresholds. Vanity metrics (clicks, “seems cheap”) do not count.

## Decision

Conclude with one of:

* `PRICE`: a recommended offer may be used externally, with named limits
* `PRICE NARROWLY`: only a pilot or single-package offer may be used
* `HOLD`: do not change public pricing
* `REVISIT OFFER`: the inherited job, product, or economics cannot support a coherent price

Lead with:

“As of [date], for [beachhead] buying [pricing unit] to complete [job], the recommended offer is [package] at [price or range], against [named alternative spend], at evidence ceiling [ICP version], with decision [PRICE / PRICE NARROWLY / HOLD / REVISIT OFFER].”

## Deliverables

Create or update only:

### 1. `docs/gtm/pricing.md`

Include the lead sentence, inheritance, pricing unit, bounds and formulas, packages, guardrails, desk tests, designed live tests, and open questions.

### 2. `docs/gtm/pricing.yaml`

Include `version`, `status`, `as_of_date`, `decision`, `confidence`, `source_icp`, `source_market`, `source_positioning`, `evidence_ceiling`, `pricing_unit`, `value_metric`, `cost_to_serve`, `price_bounds`, `recommended_package`, `packages`, `discount_policy`, `exceptions`, `assumptions`, `unknowns`, `confirmation_conditions`, `falsification_conditions`, `sources`.

Use `status: hypothesis` unless payment, retention, and unit economics have confirmed the offer. Unknown values are `null` with an explanation.

Version independently of this prompt. First hypothesis is `0.1`.

### 3. `docs/gtm/pricing-changelog.md`

Append only. Record what changed in unit, price, packages, or decision, and why.

Parse the YAML and confirm the three files agree.

## Boundaries

* Do not modify application code or overwrite ICP, market, or positioning files.
* Do not invent willingness to pay, invoices, or competitor prices.
* Do not copy a competitor’s published tiers.
* Do not treat stated enthusiasm as a price the buyer will accept.
* Do not hide founder labor in the margin.
* Do not use Good / Better / Best as decoration.
* Do not publish a price above the evidence ceiling.
* Preserve uncertainty instead of manufacturing a confident number.

## Done when

* The pricing unit, recommended package, and decision are explicit.
* Low / base / high bounds show formulas and labels.
* Cost to serve includes founder labor.
* Desk tests have been run and failures forced a narrower offer or `HOLD`.
* Live tests are designed and unrun.
* All three deliverables parse and agree.