Te cuento lo que suele pasar, creo que nos ha pasado a todos, una empresa decide «ser data-driven», contrata una herramienta de analítica, dos personas la configuran durante un mes, lanzan dos o tres dashboards en una reunión muy preparada y, seis semanas después, nadie los abre. Las decisiones siguen tomándose como antes, a ojo, y la conclusión interna suele ser la herramienta no funcionó.
La herramienta no es el problema, el problema casi siempre es que el equipo se saltó pasos. Quiso construir el tejado sin terminar los cimientos, y los dashboards sin cimientos son gráficos bonitos que no responden preguntas útiles.
En este artículo te presento el framework que mejor me ha funcionado para diagnosticar dónde está atascado un equipo y qué tiene que ordenar antes de seguir: la jerarquía de necesidades en analítica de producto. Cinco niveles, en orden, como la pirámide de Maslow, una analogía cómoda y suficientemente cercana al modo en que la analítica funciona en la práctica.
Este artículo es el mapa del bloque III, en los dos siguientes (recolectar y refinar datos y de informes a la acción) bajo al detalle de cada nivel.
Por qué muchos equipos fracasan al «ser data-driven»
Antes de la pirámide, los tres patrones de fracaso más comunes. Si te suenan, ya tienes la mitad del diagnóstico hecho.
1. Comprar la herramienta antes que tener el método: . Si tenemos Mixpanel, seremos data-driven. Spoiler: no funciona así. La herramienta solo amplifica lo que ya hay, si no tienes claro qué quieres medir, vas a tener un Mixpanel ruidoso, no un Mixpanel útil.
2. Empezar por el final: Equipos que se ponen a montar dashboards antes de definir métricas o eventos. El dashboard se construye, se usa la primera semana por parte del equipo y luego se abandona. La razón: estaba construido sobre métricas que cada persona calculaba de forma distinta, así que no se puede discutir nada con él.
3. Subestimar el cambio interno: Aunque la pirámide entera esté bien construida, si el equipo sigue decidiendo a ojo en las reuniones, la analítica no entra en la cultura. Tener datos no equivale a usarlos, es la parte que más cuesta y la que casi nadie planifica.
Los tres patrones tienen la misma raíz, saltarse niveles. Y la pirámide está diseñada precisamente para que veas dónde estás saltando.
La pirámide en cinco niveles
Nivel 1 – Recolectar datos: Tener eventos limpios, identificadores estables (user_id, account_id) y datos de personas y de comportamiento entrando a la herramienta, es decir contexto. Es la materia prima, sin esto, no hay nada.
Nivel 2 – Refinar datos en métricas: Coger los eventos en bruto y convertirlos en métricas con definición clara y compartida con el equipo. Aquí pasan dos cosas: definir nombres (qué es «usuario activo» para tu equipo) y elegir las métricas que de verdad importan (NSM, OMTM, KPIs por familia), es donde se decide qué se cuenta y cómo.
Nivel 3 – Construir reportes: Tendencias, funnels, retention charts, paths, dashboards. La capa que enseña los patrones del comportamiento en el tiempo y permite comparar. Cuanto más ambiguas son las métricas del nivel 2, menos fiables se vuelven los reportes del nivel 3: los gráficos construidos sobre métricas mal definidas son siempre discutibles.
Nivel 4 – Tomar acción: El momento en el que los reportes generan decisiones, cambios de roadmap, ajustes de onboarding, retiradas de funcionalidades, business cases. Aquí es donde la analítica empieza a tener ROI real.
Nivel 5 – Integrar la analítica en la cultura: Más que un paso, un estado. La analítica vive en cómo el equipo piensa, decide y se comunica. Las métricas aparecen en cada reunión sin que nadie las saque a propósito, es a donde se quiere llegar, no un escalón que se pisa.
La analogía con Maslow no es perfecta (en producto puedes tener el nivel 3 funcionando a medias mientras revisas el 2), pero la idea esencial sí lo es: cada nivel se apoya en el anterior y, si la base flojea, todo lo de arriba flojea con ella.
Cada nivel cambia el tipo de conversación
Una forma muy útil de mirar la pirámide: cada nivel desbloquea una pregunta nueva en las reuniones del equipo. Si te oyes a ti mismo o a tu equipo haciendo una pregunta de un nivel inferior al que deberíais estar, sabes dónde tienes el agujero.
- Nivel 1: ¿Podemos confiar en los datos?
- Nivel 2: ¿Estamos hablando de lo mismo?
- Nivel 3: ¿Qué está pasando?
- Nivel 4: ¿Qué hacemos?
- Nivel 5: ¿Cómo decidimos?
Un equipo en el nivel 2 que entra a una reunión preguntando ¿qué está pasando con la retención? está intentando saltar al nivel 3 sin haber cerrado el suyo, y la reunión va a degenerar en una discusión sobre quién tiene el número bueno. Una organización en el nivel 5 ya no se pregunta ¿qué hacemos? en cada decisión: se pregunta ¿cómo decidimos cuándo aparezca el próximo caso parecido?, y eso cambia el tipo de conversación por completo.
Por qué no puedes saltarte un nivel
Para que se vea claro, lo que pasa cuando se intenta saltar:
De 1 a 3 (saltarse refinar): El equipo tiene eventos en la herramienta y empieza a montar dashboards directamente. Resultado: tres personas miran el mismo dashboard y calculan distinto el «número de usuarios activos» porque nadie definió qué significa eso. Los dashboards se vuelven un campo de batalla sobre quién tiene la cifra correcta, no una herramienta de decisión.
De 2 a 4 (saltarse construir reportes): El equipo define la NSM y los KPIs pero no tiene forma de visualizarlos en el tiempo. Las métricas viven en un PDF que solo se mira en la reunión trimestral. No detectas problemas hasta que la métrica ya se ha hundido durante semanas.
De 3 a 5 (saltarse tomar acción): Dashboards bonitos, métricas claras, gráficas con tendencia, pero las decisiones siguen tomándose con la intuición porque nadie ha cambiado los procesos. Tener datos no es usarlos, es probablemente el salto más común y el más doloroso, porque desde fuera parece que la organización ya es data-driven (tiene los dashboards), cuando en realidad sigue igual que antes.
Y aquí la frase que resume el artículo entero: la mayoría de empresas no tiene un problema de datos, tiene un problema de comportamiento alrededor de los datos. El cuello de botella rara vez es la herramienta, suele ser el proceso de decisión del equipo. Por eso este nivel es el más difícil de subir y el que más diferencia a una organización data-informed de una que solo tiene dashboards.
El framework lo puedes trabajar en varios niveles a la vez (de hecho, casi siempre lo haces), pero no puedes presumir de estar en uno mientras el anterior es un caos, y ese es el error que la pirámide ayuda a ver.
Cómo usar el framework para diagnosticar a tu equipo
Te dejo el ejercicio que he aplicado la última vez en el equipo en el que entré y reviso el estado de la analítica de un producto. Para cada nivel, una pregunta clara, si la respuesta cojea, ahí está el trabajo que hacer, ya tienes tarea por delante.
- Nivel 1: ¿Los eventos clave del producto entran limpios y con identificadores correctos? Si la respuesta es «más o menos» o «depende del equipo», tienes trabajo aquí antes que en ningún otro lado.
- Nivel 2: ¿El equipo coincide al 100% en cómo se calcula cada métrica clave? Si tres personas calculan tu NSM y dan números distintos, no la has definido bien.
- Nivel 3: ¿Hay dashboards vivos que el equipo mira al menos cada dos semanas? Si tus dashboards son visitados una vez al mes por la persona que los montó, están muertos.
- Nivel 4: ¿Puedes citar una decisión tomada en los últimos 90 días que se haya apoyado en datos del producto? Si no, no estás tomando acción aún.
- Nivel 5: ¿La analítica aparece en cada reunión de roadmap sin que nadie tenga que sacarla expresamente? Si la respuesta es sí, enhorabuena, la analítica está integrada en la cultura del equipo.
La mayoría de equipos que conozco están atascados en los niveles 2 y 3, a todos nos ocurre y lleva tiempo. Tienes eventos, tienes ideas de métricas, pero no has cerrado la nomenclatura ni montado un sistema de reportes que el equipo use de verdad. No es un fracaso, es donde se atasca casi todo el mundo, lo importante es saberlo y ponerse manos a la obra.
Y un recordatorio del curso: la analítica no es retroactiva
Antes de cerrar, repito una de las reglas que vienen del artículo 5: la analítica no es retroactiva. Si descubres que estás atascado en el nivel 1 porque hay eventos clave sin instrumentar, el histórico de esos eventos no existe y no lo vas a poder reconstruir, solo puedes empezar a construirlo desde hoy.
Por eso lo he puesto lo primero en la pirámide, invertir en los niveles bajos es inversión a largo plazo, porque, cada mes que retrasas instrumentar bien es un mes de histórico que no vas a tener cuando lo necesites.
Resumen rápido
- La mayoría de iniciativas analíticas fallan no por la herramienta, sino porque el equipo se salta pasos. Tres patrones típicos: comprar antes de tener método, empezar por dashboards y subestimar el cambio interno.
- Cinco niveles, en orden: recolectar, refinar, construir reportes, tomar acción e integrar la analítica en la cultura, cada uno se apoya en el anterior.
- No puedes saltarte un nivel: Si lo intentas, los problemas aparecen en forma de dashboards discutibles, métricas calculadas distintas o decisiones que siguen tomándose a ojo.
- Diagnóstico autoaplicable: una pregunta clara por nivel. La mayoría de equipos están atascados en los niveles 2 y 3, y no es un fracaso, es lo normal.
- La analítica no es retroactiva. Lo que no instrumentas hoy en el nivel 1, no lo tendrás mañana en los niveles 3, 4 y 5.
Siguiente paso
Toca bajar a la base de la pirámide. En el siguiente artículo cuento cómo se trabajan los niveles 1 y 2: recolectar datos limpios y refinarlos en métricas con definición compartida. Es la parte menos vistosa del framework y la que más decide si la analítica del equipo va a servir o no.
