Skip to main content
skill CX Codex

product-economics — Claude Code skill: what it does, how to install

Evaluates unit economics, variable LLM costs, and bottom-up market size before building. Flags every number as measured or assumed.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add avelikiy/great_cto --skill product-economics -a claude-code
Open on GitHub

What product-economics does

The skill targets the brief writing phase in docs/product/** or docs/architecture/**. Rather than modeling multi-year hockey-stick forecasts, it isolates three questions: contribution margin per user, pricing logic, and reachable buyers counted from the bottom up.

Variable costs for AI tools must include frontier model token prices evaluated at the 95th percentile of consumption instead of the mean. Fixed expenses like base infra or domains are omitted here because volume cannot rescue a negative contribution margin.

Every figure requires a clear provenance tag: [source: ...] or [assumption]. When a critical cost or conversion rate is unknown, the skill forbids making up a plausible number; it logs an explicit kill criterion that terminates the initiative if breached.

What it helps with

  • calculate contribution margin per unit including LLM token costs
  • ground pricing on cost-plus, competitor anchors, or customer value
  • estimate bottom-up market size using reachable distribution channels
  • define hard project kill criteria around unknown economic variables

Example prompts for the agent

  • Fill out the Economics section in BRIEF-v1.md using Claude 3.5 Sonnet p95 token usage
  • Calculate our contribution margin per user based on docs/architecture/rag.md
  • Build a bottom-up market estimate for 100 reachable buyers via outbound email

How to install product-economics

1Skills CLI (Vercel)

npx skills add avelikiy/great_cto --skill product-economics -a claude-code

2Manually: put the files in place

~/.claude/skills/product-economics/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/product-economics/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about product-economics

How to install product-economics in Claude Code?

Run npx skills add avelikiy/great_cto --skill product-economics -a claude-code in your terminal. You can also place the skill file manually at ~/.claude/skills/product-economics/SKILL.md.

What does product-economics do?

It evaluates whether a product makes money on a per-user basis before development begins. It demands explicit provenance for every number and tests margin against heavy usage tails.

Which pricing models does the skill support?

It accepts cost-plus, competitor-anchored, or value-based pricing. It also checks what prospective buyers currently pay to solve the issue.

Source text

SKILL.md · MIT
---
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:

```markdown
## 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 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.

© avelikiy · MIT · avelikiy/great_cto

Similar skills

All skills for Finance and business →

From the same set34

signing-preflight Checks before the first commit that the signing key is loaded and unlocked, and asks the operator to unlock it up front. CX Codex +1 ★ 107repo stars secrets-rotation Turns exposed tokens, passwords, or keys into an urgent tracked task to revoke and reissue them. Runs when credentials leak into chat, logs, or commits. CX Codex +1 ★ 107repo stars quant-validation This skill lays out checks for financial-ML backtests, features, and labels. Use it to assess whether a reported result survives common validation pitfalls. CX Codex +1 ★ 107repo stars prose-style A writing contract for agent output: conclusion first, evidence over adjectives. Useful when a person reads the report, not a parser. CX Codex +1 ★ 107repo stars pre-mortem This skill works backward from a failed project to find specific causes and add safeguards to the plan. Run it before building high-impact or hard-to-reverse changes. CX Codex +1 ★ 107repo stars pm-planning Turns an approved architecture document into a Beads task list with dependencies, time-boxes and acceptance criteria. Built for the pm agent handing work to senior-dev. CX Codex +1 ★ 107repo stars outcome-roadmap Rewrites feature-heavy roadmaps into measurable outcome statements with clear business impact. Fits quarter planning and stakeholder reviews. CX Codex +1 ★ 107repo stars opportunity-solution-tree This skill maps a measurable product outcome to customer needs, candidate solutions, and experiments. Use it when a team is deciding which problem to pursue next. CX Codex +1 ★ 107repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor