MCP HubMCP Hub
SKILL·291D7A

product-economics

avelikiy
업데이트됨 6 days ago
2 조회
93
13
93
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에 등록되어 있으며 무료로 설치할 수 있습니다.

연관 스킬

llamaguard
기타

LlamaGuard는 폭력 및 혐오 발언 등 6가지 안전 범주에서 LLM 입력과 출력을 조정하기 위한 Meta의 70-80억 파라미터 모델입니다. 94-95% 정확도를 제공하며 vLLM, Hugging Face 또는 Amazon SageMaker를 사용해 배포할 수 있습니다. 이 기술을 사용하여 AI 애플리케이션에 콘텐츠 필터링 및 안전 가드레일을 손쉽게 통합하세요.

스킬 보기
cost-optimization
기타

이 Claude Skill은 리소스 적정화, 태깅 전략, 지출 분석을 통해 개발자들이 클라우드 비용을 최적화할 수 있도록 지원합니다. AWS, Azure, GCP에서 클라우드 비용을 절감하고 비용 거버넌스를 구현하기 위한 프레임워크를 제공합니다. 인프라 비용을 분석하거나, 리소스를 적정화하거나, 예산 제약을 충족해야 할 때 사용하세요.

스킬 보기
sports-betting-analyzer
기타

이 Claude Skill은 스프레드, 오버/언더, 프로프 베트를 포함한 스포츠 베팅 시장을 분석합니다. 역사적 추이와 상황별 통계를 검토하여 가치 베트를 발견하고, 교육적 목적으로 실행 가능한 권장 사항이 담긴 구조화된 마크다운 결과를 제공합니다. 개발자는 이 기능을 스포츠 베팅 분석 도구에 활용할 수 있으며, 단순히 엔터테인먼트/교육 목적으로만 설계되었음을 유의해야 합니다.

스킬 보기
quantizing-models-bitsandbytes
기타

이 스킬은 bitsandbytes를 사용하여 LLM을 8비트 또는 4비트 정밀도로 양자화하며, 최소한의 정확도 손실로 50-75%의 메모리 감소를 달성합니다. 제한된 GPU 메모리에서 더 큰 모델을 실행하거나 추론을 가속화하는 데 이상적이며, INT8, NF4, FP4와 같은 형식을 지원합니다. 이 스킬은 HuggingFace Transformers와 통합되어 QLoRA 학습 및 8비트 옵티마이저를 가능하게 합니다.

스킬 보기