MCP HubMCP Hub
SKILL·291D7A

product-economics

avelikiy
更新日 1 month ago
4 閲覧
103
13
103
GitHubで表示
その他general

について

このスキルは、貢献利益率、価格設定の根拠、ボトムアップ市場規模を計算することで、製品の収益性を分析します。推測の誤解を防ぐため、すべての数値を測定値、仮定値、不明のいずれかとして明示的に分類することが求められます。開発に着手する前に、ブリーフィング段階で財務的実現可能性を評価するためにご利用ください。

クイックインストール

Claude Code

推奨
メイン
npx skills add avelikiy/great_cto -a claude-code
プラグインコマンド代替
/plugin add https://github.com/avelikiy/great_cto
Git クローン代替
git clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/product-economics

このコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします

ドキュメント

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 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.

GitHub リポジトリ

avelikiy/great_cto
パス: skills/product-economics
0
agentic-codingai-agentsclaude-codeclaude-code-pluginclaude-code-skillsclaude-code-subagents
FAQ

よくある質問

product-economics Skillとは何ですか?

product-economics はavelikiy が作成した Claude Skillです。Skillは、Claudeが必要に応じて読み込む指示とリソースをまとめ、追加の指示なしで product-economics に関連するタスクを実行できるようにします。

product-economics をインストールするには?

このページのインストールコマンドを使用してください。product-economics をプラグインとして Claude Code に追加するか、リポジトリを skills ディレクトリにクローンし、Claudeを再起動してSkillを読み込みます。

product-economics はどのカテゴリに属しますか?

product-economics は その他 カテゴリに属します。

product-economics は無料で利用できますか?

はい。product-economics は AIMCP に掲載されており、無料でインストールできます。

関連スキル

sports-betting-analyzer
その他

このClaudeスキルは、スポーツベッティング市場(スプレッド、オーバー/アンダー、プロップベットなど)を分析し、過去の傾向や状況統計を検証することでバリューベットを特定します。教育目的のための実践的な提案を構造化されたマークダウン形式で出力します。開発者はスポーツベッティング分析ツールとして本機能を活用できますが、娯楽および教育目的に限定されている点に留意してください。

スキルを見る
llamaguard
その他

LlamaGuardは、暴力やヘイトスピーチなど6つの安全性カテゴリーにおいて、LLMの入力と出力をモデレートするMetaの70-80億パラメータモデルです。94〜95%の精度を提供し、vLLM、Hugging Face、Amazon SageMakerを使用してデプロイ可能です。このスキルを使用して、AIアプリケーションにコンテンツフィルタリングと安全策を簡単に統合できます。

スキルを見る
cost-optimization
その他

このClaudeスキルは、リソースの適正サイジング、タグ付け戦略、支出分析を通じて、開発者がクラウドコストを最適化することを支援します。AWS、Azure、GCPにわたるクラウド支出の削減とコストガバナンスの実施のためのフレームワークを提供します。インフラコストの分析、リソースの適正サイジング、または予算制約への対応が必要な際にご利用ください。

スキルを見る
quantizing-models-bitsandbytes
その他

このスキルは、bitsandbytesを使用してLLMを8ビットまたは4ビット精度に量子化し、精度の低下を最小限に抑えつつ50〜75%のメモリ削減を実現します。限られたGPUメモリでより大規模なモデルを実行したり、推論を高速化するのに理想的で、INT8、NF4、FP4などのフォーマットをサポートしています。HuggingFace Transformersと統合され、QLoRAトレーニングや8ビットオプティマイザーを可能にします。

スキルを見る