--- 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: ]` — 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: ```markdown ## Economics | | value | basis | |---|---|---| | Price / unit / month | $X | competitor-anchored `[source: pricing page, ]` | | Variable cost / unit | $Z | `[source: LLM list price, , p95 usage]` | | Contribution margin | $X−Z | derived | | What buyers pay today | $W | `[source: …]` or `[assumption]` | | Reachable buyers (bottom-up) | N | via `[assumption]` | **Kill criterion:** **Cheapest way to find out:** ``` 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 guess, and its shape persuades where its inputs cannot. - **Not a reason to refuse to build.** Plenty of things are worth building at a loss — a portfolio piece, a wedge, something you want to exist. The rule is that the loss is **stated and chosen**, not discovered in month four. - **Not investment advice**, and not a substitute for the operator's own judgement about their market.