Convertir la analítica en un deporte de equipo en WeWork

Cuando se le pregunta, casi cualquier profesional en el campo diría que el análisis de productos es un deporte de equipo. La amplitud de las responsabilidades y el trabajo requerido, desde la configuración de la infraestructura de datos hasta la definición de métricas, los informes de rendimiento y la entrega de información, es mucho más de lo que una persona podría administrar por sí sola.

Excepto que de alguna manera, a menudo lo hacen. Muchos analistas de datos trabajan bajo el radar, sabiendo que son parte de un equipo pero sintiéndose como un equipo de datos de uno.

Durante los primeros doce meses en mi función como científico de datos de productos en WeWork, fui una persona que apoyaba dos productos y cinco gerentes de productos, y también un recurso para el equipo de investigación de diseño y mis contrapartes de datos en toda la empresa. En un día típico, puedo cambiar entre docenas de tareas, habilidades y contextos: consultar el almacén de datos, crear paneles de análisis, recopilar datos para definir una métrica o realizar un análisis previo al experimento.

Entonces, aunque el análisis de productos suena como un deporte de equipo, no siempre se siente así. Creo que el problema comienza con la frase "desarrollo de productos basado en datos".

El problema con el desarrollo de productos basados ​​en datos

Dependiendo de la cultura de datos de una organización o de cuán experto en datos sea el liderazgo, existe la suposición oculta de que el profesional de datos promedio es una máquina independiente. La gente espera que los analistas saquen a la luz continuamente los conocimientos y se los entreguen al equipo de producto, quien luego los incorporará a la hoja de ruta.

Pero los datos y las perspectivas de los productos no se materializan de la nada; siempre es trabajo de alguien unir las piezas. En WeWork, se ve algo así:

• Instrumentación : alguien decide sobre qué queremos recopilar datos y lo documenta, lo que nos da la base para comenzar. (En mi caso, generalmente es la actividad del usuario front-end).
• Implementación: alguien escribe el código para implementar este seguimiento de actividad.
• Control de calidad: alguien (realmente un héroe anónimo) valida que la implementación esté generando los datos como se esperaba.
• Gobernanza: alguien administra la gobernanza de datos, asegurándose de que enviamos los datos más limpios posibles y los manejamos de manera adecuada.
• Modelado : alguien genera nuestro modelo de datos de almacenamiento de datos, desde la ingesta de datos hasta la arquitectura de una estructura escalable que satisfará las necesidades del negocio.
• Monitoreo del desempeño: alguien usa los datos recopilados para monitorear el desempeño del producto, responder preguntas esenciales y dar números concretos a las partes interesadas, mientras lo coloca en un contexto que cristaliza lo que es significativo y lo que no lo es.
• Prueba de hipótesis: alguien identifica hipótesis significativas y realiza experimentos y análisis para (con suerte) impulsar decisiones de productos y dar forma al futuro de nuestro producto.

Se necesita un pueblo para sacar a la luz los conocimientos de los datos, y un equipo de uno simplemente no es suficiente.

Los buenos datos son el subproducto de un proceso sistemático que requiere múltiples disciplinas y miembros del equipo. Se necesita un pueblo para sacar a la luz los conocimientos de los datos, y un equipo de uno simplemente no es suficiente. Cuanto más pequeño sea el equipo de datos, mayor será el riesgo de datos descuidados, problemas de rendimiento perdidos y un analista demasiado disperso para ofrecer valor.

Superar la intimidación de datos con entrenamiento 1:1

Nuestro sueño en WeWork era atraer a más personas al "equipo" de datos, pero nos costó adoptar herramientas de análisis, como Looker y Tableau. Es un problema canónico: creo que la mayoría de los profesionales de datos han entregado al menos un tablero que no se usó o se ignoró por completo. Aunque el análisis de autoservicio no es nuevo, nunca obtuvimos mucha tracción, pero lo estamos logrando con Amplitude Analytics.

Como profesional de datos, es fácil pasar por alto lo intimidantes que pueden ser los datos. Para las personas que no operan en este espacio, sigue siendo una entidad misteriosa, que solo los expertos pueden entender. Superar esta barrera de intimidación es fundamental para impulsar la alfabetización de datos. Una vez que las personas se dan cuenta de que los datos son solo información, información que puede contar una historia sobre productos y clientes, su curiosidad natural toma el control.

Mi misión era crear los 'momentos de la bombilla en los que las personas descubran lo satisfactorio que es hacer una pregunta y responderla rápidamente, utilizando herramientas de datos de autoservicio. Sabía que la intimidación es una forma de miedo, así que comencé por conocer al hombre del saco.

Algunas partes interesadas creen que solo los expertos pueden dar sentido a los datos, y superar esta barrera de intimidación es fundamental para impulsar la alfabetización de datos.

Al principio, esto comenzó con una gran cantidad de entrenamiento personalizado, cubriendo los aspectos fundamentales: cómo funciona el seguimiento, cómo identificamos a los usuarios y qué es un flujo de eventos. Luego, recorrimos la plataforma y discutimos cómo pensar sobre nuestros datos y cómo hacer preguntas que podrían responderse en Amplitude. Enseñé a mis usuarios (las partes interesadas de mi producto) cómo sentir curiosidad por los datos y cómo hacer gráficos para satisfacer esa curiosidad.

Ahora, cada vez que mi equipo de producto tiene una pregunta que no puede responder, les pido que asignen tiempo en mi calendario para que podamos resolverla juntos . Si surge algo notable, positivo o negativo, en nuestra revisión del tablero, animo al equipo a profundizar en los datos. Autorizo ​​a cada miembro del equipo a ocupar el asiento del conductor de forma independiente, pero siempre estoy dispuesto a analizar los problemas como equipo.

Uno de los mayores beneficios de este proceso de capacitación fue la familiaridad. Cuanto más cómodo se sentía mi equipo con Analytics, menos intimidantes se volvían los 'datos' en su conjunto. También se sintieron más cómodos conmigo y esa confianza ha llevado a una mejor colaboración.

El camino lento para cambiar la cultura de datos

El aprendizaje y la creación de hábitos requieren tiempo y repetición. A muchos de nosotros, los trabajadores de tecnología, se nos ha enseñado que el éxito llega cuando nos movemos rápido y rompemos cosas, pero si está tratando de cambiar la cultura de datos, deberá moderar sus expectativas.

Yo mismo tuve que hacer esto también. Supuse que una vez que las personas estuvieran familiarizadas con Analytics, desarrollarían sus propios rituales en torno a la visualización y el uso de paneles en la plataforma. Y, sin embargo, seguí respondiendo preguntas que ya estaban claramente respondidas, en gráficos y paneles existentes. Era evidente que mi equipo no estaba usando la plataforma con la frecuencia que esperaba.

Entonces, sabía que necesitaba ayudar a desarrollar el músculo del hábito. Con ese fin, configuré una revisión semanal del tablero donde los PM y yo examinamos nuestras métricas principales, usando los tableros de Amplitude. Estas revisiones periódicas inevitablemente plantean otras preguntas que podemos investigar juntos en Analytics. Por lo tanto, no solo nos acostumbramos a comenzar la semana alineándonos con las métricas, sino que al hacerlo, nos preparamos para más 'momentos de bombilla'.

Mis esfuerzos nos llevaron a alguna parte, pero lo que también ayudó fue un mensaje claro y algo de responsabilidad, desde el liderazgo del producto hasta sus equipos de producto. Cuando el liderazgo de productos dejó en claro que esperaban que los equipos de productos fueran dueños de sus métricas, no solo de los socios de datos, comenzamos a ver a más y más personas que no solo miraban los tableros, sino que exploraban por su cuenta. Esa fue una gran victoria.

Desde que comencé a trabajar en la evangelización de Analytics, hemos visto un crecimiento decente en usuarios activos. Estoy orgulloso de eso, pero estoy aún más orgulloso de nuestro crecimiento en el aprendizaje de los usuarios, personas que no solo ven paneles para su propio conocimiento, sino que también crean y comparten contenido con otros.

El objetivo: desarrollo de productos alimentado por datos

Olvídese de estar basado en datos. Nuestro objetivo es el desarrollo de productos alimentado por datos, un desarrollo de productos impulsado por el equipo de productos pero alimentado a través de una asociación con el equipo de datos. Simplemente no tiene sentido que toda la exploración de datos, la búsqueda de información y el análisis se limiten a personas con la palabra "datos" en su título. Amplitude Analytics está diseñado para permitir que todo el equipo del producto explore sus datos; en cierto sentido, que cualquier miembro del equipo de producto sea miembro del 'equipo de datos'. Y cuanto más grande sea el 'equipo de datos', más 'combustible de datos' agregará al desarrollo de productos.