/product-economics

name: product-economics
description: "Does this product make money at a price someone will pay? Forces contribution margin, a price with a stated basis, and a bottom-up market size — each number labelled measured / assumed / unknown, so a guess can never be read as a calculation."
when_to_use: |
  Apply BEFORE gate:product, while the brief is being written:
  - product-owner, in Step 4 — the Economics section of BRIEF-*.md
  - architect, when a design choice moves variable cost per user (model tier,
    context size, retrieval, image generation)
  - any time the answer to "should we build this" depends on money rather than
    on feasibility
effort: medium
allowed-tools: Read, Write, WebSearch, WebFetch
paths:
  - "docs/product/**"
  - "docs/architecture/**"

Product economics

A product can pass every gate this pipeline has — architecture reviewed, tests green, security signed off, deployed — and still lose money on every user. The pipeline is silent about that, and silence reads as approval.

This is the missing question, and it is three questions:

1. **Does a unit pay for itself?** (contribution margin) 2. **What is the price, and on what basis?** (pricing) 3. **Are there enough units to matter?** (market size, bottom-up)

The rule that makes this worth doing

**Every number carries its provenance**, in the notation the brief already uses — do not invent a second vocabulary for this:

• `[source: <where it was read>]` — an invoice, a usage log, a competitor's

published price with the date you checked it

• `[assumption]` — you made it up, and saying so is the point

`artifact-lint` already rejects a figure carrying neither. That rule was written for the Problem section; it binds here at least as hard, because arithmetic launders provenance: an `[assumption]` conversion rate and a `[source:]` one are indistinguishable once they have been multiplied together, and the product of two guesses is presented with the same confidence as a measurement.

**The third state is the one the notation has no symbol for: a number nobody knows.** Do not fill that hole with a plausible figure — a plausible figure becomes `[assumption]`, gets multiplied, and disappears into a margin. Write the line as an open question instead, and carry it into **Risks & kill-criteria** with the threshold that would end the project. An unknown that decides the answer is a finding, not a gap.

1. Contribution margin — per unit, per month

price per unit                              $
  − variable cost per unit                  $
      LLM tokens (in + out, at list price)  $   ← usually the largest, often forgotten
      inference / GPU seconds               $
      storage + egress attributable to one unit
      per-unit third-party fees (payments %, SMS, maps, email)
      support minutes × loaded hourly cost
= contribution margin                       $     ← this must be POSITIVE

Fixed costs (your time, base infra, domain) do **not** belong here. They decide when the product breaks even, not whether a unit is viable. A negative contribution margin cannot be fixed by volume — more users lose more money.

**For AI products the LLM line is the whole question.** A heavy user on a frontier model at an unmetered flat price is the classic way to build something excellent and unsellable. Compute it at **list price for the model actually configured**, at the **95th percentile** of expected usage, not the mean: flat-rate plans are priced by the tail, and the tail is what arrives.

`cost-model` covers infrastructure and LLM cost for the BUILD. This covers the cost of one user, for the LIFE of the product. Use its numbers here rather than re-deriving them.

2. Price, and the basis for it

State which of the three the price rests on. Not all three — the one that actually decided it:

• **Cost-plus** — margin over unit cost. Honest, and a floor; it never tells you

what someone will pay.

• **Competitor-anchored** — priced against a named incumbent, with the delta

justified. Name the incumbent and the price you checked, with a date.

• **Value-based** — a stated fraction of the money or hours the buyer saves.

Requires a number for what they save, which is usually `assumed`; say so.

Then the sanity check that catches most of it: **what does the buyer pay today for this problem?** Zero is a valid answer and a hard one — it means the budget does not exist yet and must be created, which is a different product.

3. Market size — bottom-up only

Top-down TAM ("the CRM market is $90B, 0.1% is $90M") is not evidence. It is arithmetic performed on someone else's report.

Bottom-up:

number of buyers you can NAME or enumerate
  × realistic annual price
  × a reachable fraction, with the channel that reaches them
= revenue you could plausibly get

If the channel cannot be named, the fraction is `unknown`, not optimistic.

For a solo operator the honest threshold is rarely "is the market big" — it is **"are there 100 buyers I can reach without a sales team"**. Ask that one.

What this produces

A section in `BRIEF-*.md`, before the recommendation:

## Economics

| | value | basis |
|---|---|---|
| Price / unit / month | $X | competitor-anchored `[source: <name> pricing page, <date>]` |
| Variable cost / unit | $Z | `[source: LLM list price, <model>, p95 usage]` |
| Contribution margin | $X−Z | derived |
| What buyers pay today | $W | `[source: …]` or `[assumption]` |
| Reachable buyers (bottom-up) | N | via <named channel> `[assumption]` |

**Kill criterion:** <the number that, if it turns out worse than T, ends this>
**Cheapest way to find out:** <the test that resolves the largest `unknown`>

Every `unknown` in that table is carried into **Risks & kill-criteria** with a threshold, so the brief cannot record an unresolved economic question as a resolved one.

What this is NOT

• **Not a forecast.** No three-year revenue curve. A curve built on `assumed`

inputs is a decorated g