north-star-tree

name	north-star-tree
description	Skill conversacional que devuelve north-star metric + árbol de inputs + guardrails. Hace preguntas sobre objetivo, modelo, restricciones y qué datos tienes medidos ANTES de proponer; si el cliente tiene web, la lee (Web Fetch) para el contexto de negocio. Cada input del árbol se ata a una columna/dato real y medible.

/north-star-tree — Conversacional

Pattern

1. Acoge — entiende el negocio (lee su web si la hay) + confirma objetivos
2. Diagnose — preguntas (incluye qué datos tienes medidos)
3. Confirma — espejo
4. Produce — north-star + árbol multiplicativo (inputs medibles) + guardrails
5. Itera — ¿ajustamos guardrails?

Flujo

Acoge · entiende el negocio (usa su web)

La north-star no se adivina del dato, se decide — pero para decidir bien hay que entender qué vende el negocio y su funnel. Si el cliente tiene web, pídela y léela con Web Fetch antes de preguntar nada:

"¿Tienes la web del cliente? Pásamela y me miro qué vende y su funnel — así no te hago escribir lo que la página ya dice."

Lo que la web te da: qué vende, modelo, etapas del funnel. Lo que la web no te da y tienes que preguntar: la decisión que sirve esta north-star y qué datos tienes medidos (abajo).

Si el usuario ya te dio parte de esto en su mensaje (web, columnas, decisión), no repreguntes: refléjalo en Confirma y salta a Produce. Las preguntas son para los huecos, no un formulario obligatorio.

Q1 · ¿Qué quieres maximizar?

"En 1 frase: ¿qué tiene que crecer? (revenue · pacientes · usage · retention)"

Q2 · Cómo cobras

"¿Modelo? (one-shot · suscripción · marketplace · ads)"

Q3 · Restricciones

"¿Límites? (operativa máxima · capacidad equipo · regulación)"

Q4 · Qué NO puedes romper

"¿Guardrails? (CAC techo · churn techo · NPS suelo · % refunds)"

Q5 · Qué tienes medido (para el árbol)

"¿Qué columnas/datos tienes ya en tu dataset? (pásame los nombres de columna). El árbol de inputs solo puede usar cosas que puedas medir de verdad — si no, es humo que no vas a poder seguir."

Produce

NORTH STAR: {métrica}
Justificación: ...

ÁRBOL INPUTS (multiplicativo)
NS = Input1 × Input2 × Input3 × Input4

INPUT 1: {nombre}
  Columna/dato real: {columna del dataset}  (o ⚠ hay que instrumentar)
  Lever: ...
INPUT 2: ...

GUARDRAILS
- {guardrail 1}: umbral X
- {guardrail 2}: umbral Y

Itera

"¿Cambio north-star? ¿Añado guardrail? ¿Te paso a /dashboard-builder?"

Reglas

• 1 sola north-star · si tienes 2 → no entiendes el negocio
• Inputs multiplicativos
• Cada input mapea a una columna/dato que YA se mide. Si un input no se mide, márcalo ⚠ hay que instrumentar o no lo metas — nada de árboles preciosos llenos de métricas que nadie puede seguir. El árbol vale lo que puedas medir de él.
• Si el cliente tiene web, léela (Web Fetch) para el contexto de negocio en vez de hacer que el usuario lo escriba.
• Min 2 guardrails (uno calidad, uno eficiencia)
• Tiempo explícito en NS (por mes, etc.)
• Si la decisión que sirve la north-star es por-segmento (p. ej. "reasigno budget por canal"), rompe el árbol por esa dimensión y añade una métrica de eficiencia por segmento (CAC/ROAS por canal) como criterio de ranking. El árbol multiplicativo puro te da el volumen, pero no te dice dónde reasignar — para eso necesitas el eje de eficiencia.

Ejemplo 1 · Hospital Capilar (one-shot)

Input: maximizar revenue · one-shot 3.500€ · capacidad 200 ops/mes · guardrails CAC<1000€, NPS>50

Output:

• NS: Pacientes nuevos cerrados / mes
• ÁRBOL: NS = Tráfico × CR_landing × CR_form × % cualif × CR_cierre
• GUARDRAILS: CAC < 1000€ · NPS > 50 · capacidad < 200/mes

Ejemplo 2 · Xuan Lan Yoga (suscripción B2C)

Input: maximizar revenue · suscripción mensual/anual · sin límite operativo (digital) · guardrails LTV/CAC > 3.0 · churn M1 < 35% · NPS > 40

Output:

• NS: Active Paying Users (APU) / fin de mes
• Justificación: APU captura simultáneamente nuevos activos + retención + reactivaciones. Es el número que mueve el MRR de forma directa. Revenue se mira aparte pero APU es la palanca.
• ÁRBOL multiplicativo:

  APU_fin_mes = APU_inicio_mes
                + Nuevos_activos (= Tráfico × CR_signup_to_trial × CR_trial_to_paid)
                + Reactivados (= Cancelados_M-1 × tasa_winback)
                − Churned (= APU_inicio_mes × churn_rate_mensual)
  

• INPUTS clave:
  • Tráfico: spend × CPC_efectivo (por canal) + orgánico
  • CR signup→trial: fricción del onboarding (UX + onboarding emails)
  • CR trial→paid: valor percibido del producto en los primeros 14 días + pricing del paid
  • Tasa winback: efectividad de las campañas de re-engagement
  • Churn mensual: salud del producto + competencia + estacionalidad
• GUARDRAILS:
  • LTV/CAC > 3.0 (umbral salud unit economics)
  • Churn M1 < 35% (umbral activation OK · si peor, problema serio de onboarding)
  • NPS > 40 (proxy salud experiencia)
  • Annual share > 30% del MRR (concentración riesgo en mensual = malo)

Diferencias clave one-shot vs suscripción

Aspecto	One-shot (HC)	Suscripción (XLY)
NS típica	Clientes cerrados / mes	Active Paying Users (APU) / mes
Árbol	Multiplicativo simple (4-5 inputs)	Multiplicativo + términos de cohort (suma de altas, restas de churn)
Restricción	Operativa (capacidad médica, agentes)	Producto (engagement, churn)
Tiempo en NS	Por mes (corto plazo)	Por mes Y por cohort (LTV a 12-24m)
Guardrail crítico	CAC techo	LTV/CAC ratio mínimo