Versión ampliada en el blog: North Star Metric y KPI Tree con Claude
Hola, ¿Qué tal estás?
Hoy te traigo dos eventos, un contenido práctico y didáctico y al final, las ofertas de trabajo en producto.
El contenido es de Esther Salinas, que usa Claude para cuestionar sus propias métricas.
Los dos eventos caen casi seguidos:
29 de septiembre, online (19:00 España). Tu second brain con IA, el webinar de Manu López y Maribel Fernandez. 90 minutos para montar un sistema donde lo que sabes queda ordenado y una IA puede buscarlo, conectarlo y usarlo contigo, con un caso real construido con Claude Code. Estaré yo hablando del encaje entre mercado y candidato.
30 de septiembre, Barcelona. Cómo la IA está cambiando los productos que usamos, cómo los construimos y cómo trabajan los agentes para nosotros, con Glòria Langreo (Senior Design Director en Github), Jonathan (VP of Product Design en Factorial) y João Mello (founder, editor de Bold, ex-DoorDash). El punto de partida: de productos, experiencias y equipos agentic es fácil hablar; hacer que funcionen juntos en la práctica es otra cosa.
Y una duda: estamos analizando más de 3.000 ofertas de trabajo en producto. ¿Qué te gustaría ver? Respóndeme a este email y me lo cuentas.
El contenido
Esta semana en Be Product tenemos a Esther Salinas, Product Manager en Lidl International Hub, donde lidera las experiencias de engagement de Lidl Plus, una app que usan millones de personas.
Su camino al producto es de los que más nos gustan: empezó en desarrollo y QA, pasando por eDreams, GFT y Desigual, así que habla el idioma de Engineering con total naturalidad.
Hoy lidera un squad multidisciplinar y trabaja la estrategia de producto codo con codo con la CPO, midiendo por impacto y no por output.
Es una apasionada de la experimentación y los datos, y sus iniciativas de push e in-app messaging han mejorado el CTR para millones de usuarios.
Además, se está metiendo de lleno en IA y automatización con herramientas como Claude Code y n8n, y comparte lo que aprende en su newsletter IA con Esther, que os recomiendo seguir.
Aquí va:
Claude no solo puede ahorrarte tiempo. También puede ayudarte a ser mejor Product Manager
Hace unos días publiqué una encuesta en LinkedIn para decidir sobre qué escribir en mi próxima newsletter.
Había dos opciones que destacaban:
5 tareas de Product que delegaría a Claude Cowork
Cómo he creado una Skill de Claude para resolver un problema real de Product
Y pasó algo curioso: empataron.
Así que, en lugar de elegir una y descartar la otra, decidí aprovechar el empate.
Había una razón para hacerlo: mientras probaba algunas de esas tareas con Claude, me di cuenta de que una de ellas podía convertirse en algo más interesante.
Una Skill que me ayudara a trabajar un problema real de Product de forma repetible.
Y acabé eligiendo esta segunda opción.
Pero no quería hacer una Skill porque sí.
Quería probarla con un producto que pudiera enseñar de principio a fin, sin restricciones:
Mi propia newsletter, IA con Esther.
Y aquí empezó el experimento.
En este post vas a ver:
→ Cómo usé Claude para poner a prueba mi propia intuición sobre qué métrica debería importarme y por qué falló.
→ El proceso real (con datos de mi propia newsletter) para definir un North Star Metric que no fuera una vanity metric disfrazada.
→ Un hallazgo que no esperaba: suscriptores que llevan meses sin recibir ni un solo email, sin que yo lo supiera.
→ Cómo construí dos Skills de Claude reutilizables a partir de esto — publicadas y libres para que las uses en tu propio producto.
→ Por qué lo más útil no fue que Claude me diera respuestas, sino que me ayudara a hacerme mejores preguntas.
Gracias por leer IA con Esther! Suscríbete gratis para recibir nuevos post y apoyar mi trabajo
1. Empezar por la estrategia
Antes de pensar en métricas, tuve que hacerme una pregunta bastante sencilla:
¿Qué quiero conseguir realmente con mi newsletter?
Mi objetivo ahora mismo es:
Hacer crecer IA con Esther dentro de la comunidad de Product, con el objetivo de poder ofrecer formaciones en el futuro.
Esto parece bastante claro.
Pero inmediatamente aparece una segunda pregunta:
¿Cómo sé si realmente estoy avanzando hacia ese objetivo?
Porque podría decir simplemente:
“Quiero conseguir más suscriptores.”
Pero eso no necesariamente significa que esté construyendo el producto que quiero construir.
Y aquí decidí utilizar Claude para hacer algo que hacemos constantemente en Product:
Cuestionar nuestras propias suposiciones.
2. Definir mi North Star Metric
Últimamente he estado bastante obsesionada en hacer crecer mi newsletter , de hecho gracias a unas skills (que ya publicaré en otro post) he conseguido hacer crecer el número de suscriptores de manera exponencial en el último mes y medio
Mi intuición fue:
Más suscriptores = más audiencia = más potenciales alumnos.
¿No?
Pues no necesariamente.
Puedes tener muchos suscriptores que nunca abren tus emails.
Puedes conseguir cientos de registros gracias a un post viral y que después no vuelvan.
Puedes tener una audiencia pequeña pero extremadamente comprometida.
Y, sobre todo, el número de suscriptores no me dice necesariamente si estoy creando valor para la comunidad de Product.
Como construí la skill de north star metric
El proceso fue bastante sencillo: le expliqué qué quería conseguir y le proporcioné como referencia la documentación del North Star Framework de Amplitude.
A partir de ahí, Claude me ayudó a seguir los pasos necesarios para convertir ese conocimiento en una Skill que pudiera reutilizar.
No tuve que escribir la Skill desde cero.
De hecho, una de las cosas que más me está gustando de trabajar con Claude Code es precisamente esta posibilidad: puedes partir de un framework o metodología que ya existe y convertirlo en una herramienta que te ayude a aplicarlo de forma consistente.
La referencia que utilicé fue:
👉 North Star Framework — Amplitude
Y si quieres ver el proceso que utilicé para crear una Skill desde cero, lo expliqué en un post anterior:
👉 Cómo crear una Skill de Claude para Product Managers
Es mucho más sencillo de lo que parece: Claude te va guiando durante el proceso y tú aportas el conocimiento, el contexto y las reglas que quieres convertir en una herramienta reutilizable.
Nota: Las dos skills que verás en este post están publicadas en Git: Enlace
Una vez creada la skill, le planteé a Claude el problema.
Quiero hacer crecer una newsletter sobre IA aplicada a Product dentro de la comunidad de Product Managers, con el objetivo de poder ofrecer formaciones en el futuro. Ayúdame a definir una North Star Metric que esté alineada con esta estrategia.
Le pasé información exportada de substack donde aparecen para cada newsletter datos como open rate, vistas y suscripciones.
Antes de sugerirme nada, Claude puso a prueba mi primera intuición: “suscriptores totales”.
El framework de North Star tiene un checklist de 7 preguntas para esto. Cosas como: ¿expresa valor real para el lector? ¿Es un indicador que anticipa el futuro, o solo cuenta lo que ya pasó? ¿Es una vanity metric?
Mi propuesta falló en 3 de las 7.
La razón principal: “suscriptores totales” es, estructuralmente, el mismo tipo de métrica que “Registered Users” — uno de los ejemplos de vanity metric que el propio framework pone como advertencia. Cuantas personas que se apuntaron una vez, no personas que siguen sacando valor.
Claude me sugirió que buscase información sobre lectores recurrentes así que busqué esa información en substack y le pasé el export con datos como la fecha de suscripción, los emails recibidos, numero de emails abiertos en los últimos meses, etc.
Ejemplo de unas de las interacciones:
Dos cosas que cambian la definición
1. El campo correcto no es “opened (30d)” sino el ratio a 6 meses. Usé Unique emails seen (6mo) / Emails received (6mo) en vez de Emails opened (6mo) — este último cuenta eventos de apertura (puede superar el nº de emails recibidos si alguien reabre el mismo email varias veces; vi ratios de hasta 45x). Unique emails seen es la versión deduplicada, nunca supera lo recibido. Y usar el ratio sobre “recibidos en 6 meses” (no un calendario fijo de 30 días) resuelve exactamente el problema de cadencia irregular que comentábamos: el denominador se ajusta a cuántos emails le llegaron a esa persona, no a un reloj global.
2. Hallazgo que no esperaba y que cambia los inputs: 26 suscriptores (de los que llevan más de 6 meses en la lista) tienen 0 emails recibidos en los últimos 6 meses, sin bounces registrados (Emails dropped (6mo)=0) y sin ningún Last email open. No están de baja (no hay Cancel date), simplemente Substack parece haber dejado de enviarles — muy probablemente su propia optimización de entregabilidad suprimiendo a gente que dejó de abrir hace tiempo. Son ~6% de la lista que ninguna mejora de contenido puede recuperar, porque ni siquiera les llega el email. Esto es una palanca distinta a “calidad de la edición” — hay que añadirla como input.
Definición actualizada de Lectores Recurrentes
Nombre: Lectores Recurrentes (LR)
Definición: suscriptores free con al menos 1 email recibido en los últimos 6 meses, cuyo ratio emails únicos vistos (6mo) / emails recibidos (6mo) es ≥ 0.5 — es decir, abren al menos la mitad de lo que les llega.
Por qué el umbral 0.5 y no otro: lo saqué de la distribución real, no a ojo (a diferencia del “2 de 3” que propuse la sesión pasada sin datos). Con este umbral:
- 163 de 438 suscriptores (37.2% de la lista total) son Lectores Recurrentes hoy.
- La mediana real del ratio es 0.33 (la persona “típica” abre 1 de cada 3) — por eso 0.5 no es un umbral trivial, exige estar claramente por encima de lo típico.
Checklist, punto 6 (medible) — ya se puede marcar en verde
Antes era ✗ (brecha real). Ahora: 🟡 verificado pero manual — se calcula desde este export de Substack, que no es un dashboard en vivo pero sí es un dato real y repetible (puedes volver a pedirlo/descargarlo cuando quieras). Ya no es una promesa a futuro.
Inputs — añado uno nuevo (pasan de 5 a 6)
6. Salud de la lista / entregabilidad — el % de suscriptores a los que Substack directamente ha dejado de enviar. Es accionable (limpieza de lista, campañas de re-permiso, vigilar reputación de envío) pero es independiente de los otros 5 — puedes escribir la mejor edición del mundo y no mover nada aquí si el problema es de entrega, no de contenido.
¿Quieres que actualice el documento completo del North Star con esto (y de paso lo guardo como archivo en el proyecto), o prefieres que sigamos directamente a kpi-tree para decomponer estos 6 inputs con este North Star ya validado con datos reales?De repente, una métrica que parecía bastante sencilla se convirtió en una pregunta de Product:
¿Qué está pasando realmente entre el momento en que alguien se suscribe y el momento en que se convierte en lector?
Y ahí aparecen nuevas preguntas:
¿Por qué no está recibiendo los emails?
¿Hay problemas en el proceso de suscripción?
¿Qué porcentaje de mis suscriptores está realmente activo?
¿Por qué hay lectores que dejan de repente de serlo?
Esto es precisamente lo que buscaba cuando empecé el experimento.
El objetivo era que Claude me ayudara a encontrar preguntas que yo no estaba haciendo.
La North Star final
Después de varias iteraciones descubrimos que para mi objetivo la north star sería:
Lectores Recurrentes : ratio emails únicos vistos (6mo) / emails recibidos (6mo) es ≥ 0.5
Definición actualizada de Lectores Recurrentes
Nombre: Lectores Recurrentes (LR)
Definición: suscriptores free con al menos 1 email recibido en los últimos 6 meses, cuyo ratio emails únicos vistos (6mo) / emails recibidos (6mo) es ≥ 0.5 — es decir, abren al menos la mitad de lo que les llega.
Por qué el umbral 0.5 y no otro: lo saqué de la distribución real, no a ojo (a diferencia del “2 de 3” que propuse la sesión pasada sin datos). Con este umbral:
- 163 de 438 suscriptores (37.2% de la lista total) son Lectores Recurrentes hoy.
- La mediana real del ratio es 0.33 (la persona “típica” abre 1 de cada 3) — por eso 0.5 no es un umbral trivial, exige estar claramente por encima de lo típico.Detalle de la explicación de Claude sobre la north star
3. Ahora sí: construir el KPI Tree
Una vez tenía una North Star, la siguiente pregunta era:
¿Qué factores están impulsando esta métrica?
Para conseguirlo, creé mi propia skill, de la misma manera que hice con la skill anterior.
Y aquí le pedí a Claude que construyera un KPI Tree alrededor de mi North Star.
Después de algunas conversaciones el KPI Tree resultante fue el siguiente:
Cosas importantes que hemos detectado:
Había algo a lo que no había prestado suficiente atención: muchos suscriptores recién llegados tardan en recibir su primer email. Esto se debe, en parte, a mi cadencia de publicación. No he sido todo lo constante que debería y, si un nuevo suscriptor se apunta y después pasa un periodo largo sin recibir una nueva newsletter, es difícil que llegue a crear el hábito de leerla.
Y esto es importante porque un suscriptor que deja de recibir contenido durante demasiado tiempo puede acabar siendo un suscriptor perdido, aunque siga apareciendo como suscrito.
También he encontrado otro punto que necesito investigar: hay suscriptores que no están recibiendo la newsletter.
Aquí tengo que entender qué está ocurriendo, porque algunos clientes de correo pueden bloquear el tracking de aperturas y hacer que las métricas no reflejen exactamente el comportamiento real de los lectores. Además tengo que averiguar si hay lectores que no lo hacen a través del email y son solo lectores de substack, con lo cual tendría que redefinir la north star teniendo en cuenta este escenario.
Mi conclusión es bastante clara:
Necesito seguir trabajando en adquisición, pero ahora mismo mi foco debería estar en activación y retención.
Ya tengo suficiente volumen de suscriptores como para que el siguiente paso no sea simplemente conseguir más.
Ahora necesito conseguir que los nuevos suscriptores entiendan rápidamente el valor de la newsletter, reciban contenido de forma consistente y encuentren un motivo para volver semana tras semana.
Porque de poco sirve seguir llenando el funnel si después no estoy cuidando lo que ocurre dentro de él.
Resumen de mi funnel, teniendo en cuenta el resultado de las palancas del KPI tree
4. Lo interesante no fue que Claude propusiese una North star o construyera el KPI Tree
Claude puede generar un KPI Tree en segundos.
Eso no es especialmente sorprendente.
Lo interesante fue poder seguir conversando sobre el razonamiento detrás del árbol.
Por ejemplo:
¿Qué métricas de este árbol son realmente accionables?
¿Qué relaciones causales estamos asumiendo?
¿Qué métricas podrían ser métricas de vanidad?
¿Qué información necesitaría para saber por qué una métrica está cambiando?
¿Qué hipótesis debería investigar primero?
Y ahí Claude empieza a comportarse menos como un generador de texto y más como una compañera de análisis.
Mi aprendizaje
Si algo me llevo de este experimento es que Claude no tiene por qué ser solamente una herramienta de productividad.
Puede ayudarte a hacer tareas recurrentes más rápido.
Pero también puede ayudarte a:
→ estructurar problemas
→ cuestionar hipótesis
→ explorar alternativas
→ detectar gaps
→ descubrir preguntas que no estabas haciendo
Y creo que ahí es donde la IA empieza a ser mucho más interesante para Product.
No se trata solo de:
“¿Qué trabajo puedo delegar a Claude?”
Sino también de:
“¿Cómo puedo utilizar Claude para pensar mejor sobre mi trabajo?”
Y esa es una pregunta que quiero seguir explorando.
¿Utilizas IA para analizar tus productos, definir métricas o diseñar experimentos?
Me interesa especialmente saber qué partes del proceso de Product estás empezando a trabajar conjuntamente con IA.
Respóndeme a este email o cuéntamelo en LinkedIn.
Puede que tu caso sea el próximo experimento de IA con Esther.
Las ofertas de Product Hunter
Actualmente estoy buscando 2 posiciones:
Scrum Master - Ecommerce · Híbrido Madrid (1 día/semana) - 42K–62K + 7% variable
Senior Product Manager - SAS B2B - IA backoffice for restaurants · Híbrido Barcelona (2 días oficina) — 45K–60K
Muy buena semana
Javi Platón
👉 Ofertas que gestiono: empleo.beproduct.es/jobs
👉 Todas las ofertas de producto: beproduct.es/ofertas-producto
👉 Salarios de producto 2026: beproduct.es/informe-salarios
👉 Únete a la comunidad: beproduct.es/unete-comunidad-producto
👉 Sigue leyendo en el blog: Cómo diseñar productos con IA: el framework PRAXIS · Product Manager vs Product Engineer con la IA
