product-economics
Acerca de
Esta habilidad analiza la rentabilidad de un producto calculando su margen de contribución, base de precios y tamaño de mercado ascendente. Obliga a etiquetar explícitamente todos los números como medidos, asumidos o desconocidos para evitar malinterpretaciones de estimaciones. Úsala durante la fase de briefing para evaluar la viabilidad financiera antes de comprometerse con el desarrollo.
Instalación rápida
Claude Code
Recomendadonpx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/product-economicsCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
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:
- Does a unit pay for itself? (contribution margin)
- What is the price, and on what basis? (pricing)
- 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
assumedinputs 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.
Repositorio GitHub
Preguntas frecuentes
¿Qué es el Skill product-economics?
product-economics es un Skill de Claude creado por avelikiy. Los Skills agrupan instrucciones y recursos que Claude carga cuando los necesita para realizar tareas relacionadas con product-economics sin indicaciones adicionales.
¿Cómo instalo product-economics?
Usa los comandos de instalación de esta página: añade product-economics a Claude Code como plugin o clona su repositorio en tu directorio de skills y reinicia Claude para cargarlo.
¿A qué categoría pertenece product-economics?
product-economics pertenece a la categoría Otro.
¿Se puede usar product-economics gratis?
Sí. product-economics aparece en AIMCP y se puede instalar gratis.
Habilidades relacionadas
Esta habilidad de Claude analiza los mercados de apuestas deportivas, incluyendo spreads, over/unders y apuestas de propuestas, mediante el examen de tendencias históricas y estadísticas situacionales para identificar apuestas de valor. Proporciona una salida en markdown estructurado con recomendaciones accionables con fines educativos. Los desarrolladores deben utilizar esto para herramientas de análisis de apuestas deportivas, teniendo en cuenta que está diseñado únicamente para entretenimiento/educación.
LlamaGuard es el modelo de Meta de 7-8B parámetros para moderar las entradas y salidas de LLM en seis categorías de seguridad como violencia y discurso de odio. Ofrece una precisión del 94-95% y puede implementarse usando vLLM, Hugging Face o Amazon SageMaker. Utiliza esta skill para integrar fácilmente filtrado de contenido y barreras de seguridad en tus aplicaciones de IA.
Esta Skill de Claude ayuda a los desarrolladores a optimizar los costes en la nube mediante el ajuste de tamaño de recursos, estrategias de etiquetado y análisis de gastos. Proporciona un marco para reducir los gastos en la nube e implementar una gobernanza de costes en AWS, Azure y GCP. Úsala cuando necesites analizar los costes de infraestructura, ajustar el tamaño de los recursos o cumplir con restricciones presupuestarias.
Esta habilidad cuantiza LLMs a precisión de 8 o 4 bits utilizando bitsandbytes, logrando una reducción de memoria del 50-75% con pérdida mínima de precisión. Es ideal para ejecutar modelos más grandes en memoria GPU limitada o para acelerar la inferencia, admitiendo formatos como INT8, NF4 y FP4. La habilidad se integra con HuggingFace Transformers y permite entrenamiento QLoRA y optimizadores de 8 bits.
