Pasamos cuatro meses construyendo análisis de auto-servicio, y luego vi a la gente intentarlo. Seré honesto acerca de lo que provocó esto.No fue una curiosidad intelectual. El billete decía: “Dashboard no funciona”. lo abrí esperando un filtro roto o una actualización de datos que faltaba. En su lugar, encontré un mensaje de tres párrafos de un gerente de producto explicando que había estado mirando el dashboard durante veinte minutos y todavía no podía averiguar si su lanzamiento de la función había sido exitoso. El dashboard funcionaba perfectamente. Cada gráfico se cargaba. Cada filtro respondió. Los datos eran frescos, precisos y bien modelados. Yo lo había construido yo mismo, y me sentía orgulloso de ello. Todavía no pudo responder a su pregunta. Esa tarjeta se sentó en mi cabeza durante semanas. Finalmente, decidí hacer algo que nunca había hecho antes. Tomé uno de nuestros dashboards más utilizados y vi cinco equipos diferentes tratar de usarlo para una decisión real. No una demostración. No una sesión de entrenamiento. Una pregunta real que realmente necesitaban respondió esa semana. El establecimiento El dashboard era el resumen de nuestro compromiso con el producto. Tenía usuarios activos diarios, tasas de adopción de características, curvas de retención y un puñado de métricas adyacentes a los ingresos. Fue construido en Looker, conectado a un modelo dbt bien probado, actualizado cada cuatro horas. Seleccioné cinco equipos que regularmente accedían a este dashboard de acuerdo con nuestros registros de uso. Product quería saber si un reciente rediseño de embarque había mejorado la activación. El marketing quería saber qué canales estaban impulsando a los usuarios de mayor valor. El éxito del cliente quería saber qué cuentas mostraban señales tempranas. Las ventas querían saber si los patrones de uso correlacionaban con la disponibilidad de subida. Finance quería saber si la tendencia de costes por usuario era sostenible en el crecimiento actual. Los mismos datos. Cinco preguntas reales de cinco equipos reales, todas debidas a esa semana. Le pregunté a cada equipo si podía sentarme con ellos (o unirme a su llamada de vídeo) mientras trabajaban a través de su pregunta usando el dashboard. Admitiré mi prejuicio de antemano. esperaba que al menos tres de los cinco obtendrían lo que necesitaban. Yo había construido este dashboard con un uso cross-funcional en mente. Yo había añadido descripciones de contexto a cada gráfico. Incluso había escrito un breve how-to-doc que nadie, como resultó, había leído. Lo que realmente sucedió Producto El equipo de producto pasó los primeros ocho minutos tratando de aislar su cohorte de embarque.El panel tenía un filtro de fecha y un filtro de características, pero no tenía filtro de cohorte.Tenían que comparar a los usuarios que se inscribieron antes del rediseño con los usuarios que se inscribieron después. El PM abrió un editor SQL en una pestaña separada. escribió una consulta para sacar ID de usuario por fecha de registro, luego trató de pegarlos en el filtro de dashboard. El filtro tenía un límite de valor de 100. Ella se rindió y me sacudió, pidiendo un corte personalizado de los datos. Tiempo total en el dashboard: catorce minutos. Decisión tomada desde el dashboard: ninguno. El marketing El marketing tuvo el fracaso más interesante porque técnicamente encontraron lo que estaban buscando.El dashboard mostró fracturas de canales de adquisición. Podían ver que el social pago estaba impulsando a los usuarios más nuevos. El problema: el dashboard mostró volumen, no valor. Sociales pagados tenían el mayor número de usuarios, pero la tasa de retención más baja (que era visible en una pestaña diferente; no hicieron clic) y el valor medio del contrato más bajo (que estaba en un dashboard completamente diferente). Tomaron una decisión. Fue la equivocada. lo marcé después de la sesión. Estuvieron agradecidos pero también frustrados. "¿Por qué no nos muestra el dashboard qué canal es mejor?" preguntó uno de ellos. Porque “mejor” significa algo diferente para cada equipo. El dashboard mostró métricas. No mostró respuestas. Esa es una filosofía de diseño a la que volveremos. El éxito del cliente El éxito del cliente fue el equipo que realmente tuvo éxito, y vale la pena entender por qué. Su liderazgo había pasado tres meses construyendo un modelo mental de lo que se veía en las primeras etapas.Sabía la combinación específica de señales: logins semanales disminuidos, ninguna adopción de características más allá del flujo de trabajo principal, y la frecuencia del ticket de soporte por encima de un umbral.No necesitaba el dashboard para decirle la respuesta.La necesitaba para confirmar lo que ya sospechaba. Abrió el dashboard, filtró a sus cuentas, comprobó tres gráficos en secuencia y dijo: "Sí, estas cuatro cuentas necesitan llamadas de intervención esta semana". El dashboard trabajó para ella porque ya sabía qué buscar y cómo leer las señales juntas. Ventajas Las ventas pasaron doce minutos en el dashboard y luego me preguntaron una pregunta que todavía pienso: "¿Puedes decirme qué cuentas llamar?" Querían una lista clasificada.El dashboard les dio dimensiones y medidas.Podían ver las tendencias de uso por cuenta, pero traducir "el uso de esta cuenta aumentó un 40% el mes pasado" en "esta cuenta está lista para una conversación de subida" requería un contexto que el dashboard no tenía. No sabía la fecha de renovación del contrato, el nivel del plan existente o si la cuenta ya había sido contactada. Ella dijo que el dashboard era "interesante", que es el equivalente comercial de "nunca volveré a abrir esto". Financiación Finance no usó el dashboard. Exportaron los datos subyacentes a una hoja de cálculo en los primeros dos minutos. Cuando le pregunté por qué, la respuesta fue simple: "Tengo que construir un modelo, no mirar un gráfico". Necesitaron ejecutar escenarios.¿Qué sucede con el coste por usuario en un 20% de crecimiento frente al 40% de crecimiento?¿Cuál es el punto de inflexión?El dashboard mostró el estado actual. No lo considero un fallo de tablero. Es un error de caso de uso. Pero plantea una pregunta sobre si deberíamos haber construido a este equipo un modelo de tablero en lugar de una pestaña de tablero. El Scorecard 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Team 
 Found relevant data? 
 Answered their question? 
 Made a decision? 
 Time spent 
 
 
 
 
 
 
 Product 
 Partially 
 No 
 No 
 14 min 
 
 
 
 
 
 
 Marketing 
 Yes 
 Yes (incorrectly) 
 Yes (wrong one) 
 18 min 
 
 
 
 
 
 
 Customer Success 
 Yes 
 Yes 
 Yes 
 6 min 
 
 
 
 
 
 
 Sales 
 Partially 
 No 
 No 
 12 min 
 
 
 
 
 
 
 Finance 
 Yes 
 N/A (wrong format) 
 No 
 2 min Producto parcialmente No No 14 minutos El marketing Sí Sí (de forma incorrecta) Sí (el uno equivocado) 18 minutos El éxito del cliente Sí Sí Sí 6 minutos Ventajas parcialmente No No 12 minutos Financiación Sí N/A (formación incorrecta) No 2 minutos Lo que aprendí que no esperaba El resultado más peligroso es una respuesta equivocada confiada. La experiencia del marketing me asustó más que cualquier otra. El dashboard les dio datos. Ellos interpretaron los datos. Ellos concluyeron. La conclusión fue equivocada porque el dashboard mostró una imagen incompleta, y no tenían razón para sospechar que era incompleta. Un dashboard que te da una respuesta equivocada, crees, es peor que un dashboard que no te da nada en absoluto. Al menos "No sé" no desencadena una redistribución del presupuesto. La brecha entre las métricas y las decisiones es enorme. Cada equipo llegó con una pregunta. Ninguna de esas preguntas podría ser respondida por un solo gráfico. Las decisiones requieren combinar múltiples señales, aplicar el contexto empresarial y hacer una llamada de juicio. Los dashboards muestran métricas. La traducción de las métricas a las decisiones ocurre enteramente en la cabeza humana, y la mayoría de los dashboards dan ese proceso de traducción soporte cero. La experiencia del dominio es el verdadero filtro. El éxito del cliente se logró debido a la experiencia de su líder, no debido al diseño del dashboard. Ella sabía qué buscar. Todos los demás estaban navegando, esperando que la visión correcta saltara. El análisis de auto-servicio asume la experiencia del dominio que la mayoría de los equipos aún no han construido. Nadie lee la documentación.He escrito descripciones de contexto.He escrito una guía de cómo hacer.He añadido explicaciones de herramientas a cada métrica.Los datos de uso muestran que cero personas (no baja, cero) han hecho clic en las descripciones métricas en el último trimestre.La gente no lee la documentación en línea en los dashboards por la misma razón que no leen los términos de servicio. Los equipos que exportan a las hojas de cálculo no lo están haciendo mal. El instinto de las finanzas para exportar fue la respuesta más racional a su necesidad real. Tratamos las exportaciones de hojas de cálculo como un fracaso de nuestra capa de BI. Tal vez sea en realidad una señal de que algunos usuarios necesitan datos interactivos, manipulables en lugar de visualizaciones curadas. Construir un dashboard para alguien que necesita una hoja de cálculo es como construir un informe para alguien que necesita una conversación. "Self-Serve" es un espectro, no un interruptor. El éxito del cliente era self-serving. El producto podría haber sido self-serving con un mejor filtro de cohorte. El marketing necesitaba guarderías. Las ventas necesitaban un motor de recomendación, no un dashboard. La financiación necesitaba datos crudos con modelado de escenarios. Los llamamos todos "usuarios de análisis de auto-servimiento" y les dieron toda la misma herramienta. Lo que cambié después He reconstruido el dashboard, pero la reconstrucción no fue lo que esperabas. No añadió más gráficos. añadió menos. Suprimí tres pestañas y consolidé las restantes alrededor de una sola pregunta: "¿Esta métrica es sana, relevante o crítica?" añadió la formatación condicional que convierte las tarjetas en rojo, amarillo o verde en función de los umbrales definidos por el equipo. No estoy orgulloso de lo simple que parece ahora. Para Product, construí una herramienta de comparación de cohortes separada. Es fea. Es un Looker Explore parametrizado con dos pickers de fecha y un cálculo del delta. hace una cosa. Para Marketing, agregé una puntuación compuesta que combina el volumen, la retención y el valor del contrato en una única métrica de eficacia de canal. Todavía pueden ver los componentes, pero la vista predeterminada responde a la pregunta real: qué canal es mejor por dólar retenido. Para las ventas, renuncié a los dashboards por completo. Construí una lista de cuentas con puntuación que se ejecuta semanalmente, clasifica las cuentas por señales de subida y aterriza en un canal Slack. Tardó menos tiempo en construir que la pestaña del dashboard que sustituí. Para Finanzas, he creado un modelo de Google Sheet que extrae datos en vivo a través de la API de Looker. El hilo común: he dejado de preguntar "¿Qué métricas necesita este equipo?" y empecé a preguntar "¿Qué decisión toma este equipo repetidamente, y cuál es el camino más corto de los datos a esa decisión?" Lo que yo diría a mi pasado Construye para la decisión, no los datos.Si no puedes nombrar la decisión específica que un dashboard debe apoyar, estás construyendo una exposición de museo. Mira a alguien usando tu dashboard antes de enviarlo. No una demostración de las partes interesadas donde se tocan. Una sesión de trabajo real donde tratan de responder a una pregunta que les importa. Aprenderás más en veinte minutos de observación que en un mes de reuniones de requisitos. El mejor BI no es siempre un dashboard. A veces es una alerta Slack. A veces es una hoja de cálculo con datos en vivo. A veces es una lista de puntos. El medio debe coincidir con el patrón de decisión, no al revés. Y si tus registros de uso muestran que las personas abren tu dashboard y se van dentro de dos minutos, el dashboard no es lento. La parte más difícil de la inteligencia empresarial no es construir el modelo de datos; es comprender lo que las personas realmente hacen cuando abren su trabajo.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Este audio es producido en el idioma original de la historia!

He dado a 5 equipos el mismo dashboard - Solo 1 tomó una decisión con él

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps