Cómo crear un equipo de datos en una startup

• La historia de alguien que se unió para hacer crecer un pequeño equipo de datos de unas 4 personas en una startup mid-stage con ventas anuales del orden de 10 mil millones de wones

• Es un texto metafórico basado en varias experiencias, y puede ser sesgado*, así que léelo teniendo eso en cuenta

1 de julio: mañana

• Primer día de trabajo como responsable del equipo de datos

• Saludo con el CMO

  (El CMO está muy entusiasmado con mi llegada; me cuenta que en la empresa de un amigo están haciendo segmentación de clientes con AI y que eso se ve genial)

  (Después de una charla breve, investigo las prácticas de datos del equipo de marketing)

  DATA: "¿Cómo va el costo de adquisición de clientes (CAC)?"

  CMO: "Mmm... en realidad muy bien. Nuestro data scientist midió las cifras y el costo por clic sigue bajando"

  DATA: (Había escuchado que todos los data scientists reportaban al equipo de datos, ¿pero hay un data scientist en otra área?)

  CMO: "El verdadero problema es que el equipo de Growth no está convirtiendo todo el tráfico que llevamos al sitio"

  DATA: "¿Hay algún dashboard donde se pueda ver el embudo de conversión?"

  CMO: "Convertir leads es trabajo del equipo de Growth."

• Conversación con uno de los Product Managers

  El PM que rediseñó por completo la página de inicio estaba emocionado porque el número de registros de usuarios había aumentado 14%

  DATA: "¿Esa diferencia es estadísticamente significativa?"

  PM: "Ese no es mi trabajo, es trabajo de tu equipo"

  PM: "Cuando preguntamos antes, el equipo de datos nos dijo que no había datos y que tomaría meses conseguirlos"

  PM: "Lo increíble es que no hicimos este cambio de forma incremental. Decidimos no hacer A/B testing para este cambio. A veces hay que hacer grandes apuestas para salir de un extremo local (Local Maxima)."

  PM: "Steve Jobs no hizo A/B testing cuando lanzó el iPhone. Nuestro equipo lanzó esto 2 días antes del deadline, ¡y eso es lo importante!"

  DATA: (Garabatea en su libreta fingiendo que está ocupado)

• Conversación con los nuevos miembros del equipo

  → Es un equipo de 3 personas, pero recibieron presupuesto para crecer a 10 antes de fin de año

  → Parece que los integrantes están emocionados con mi llegada

  → Me muestran lo que han construido hasta ahora. Hay bastantes cosas y algunas son geniales

    ✓ Red neuronal para predecir abandono de usuarios (Churn Prediction)

    ✓ Notebook con un sistema de recomendación de productos relacionados implementado

  → Mucho del código empieza con pasos de preprocesamiento muy complejos que requieren traer datos desde distintos sistemas

    ✓ Parece que para ejecutar parte de esto hay varios scripts que deben correrse manualmente en el orden correcto

  → Cuando les pregunto por qué no lo han llevado a producción

    ✓ Dicen que los ingenieros consideran que convertir esto en algo de nivel de producción sería un proyecto muy grande

    ✓ El Product Manager sí lo puso en el backlog, pero siguen apareciendo otras cosas y se ha ido postergando

    ✓ Dicen que hace falta apoyo de la dirección para esto

1 de julio: tarde

• Conversación con el Head of Supply Chain (no parece tan emocionado como el CMO)

  "Sinceramente, no sé si necesitamos la ayuda del equipo de datos"

  "Nosotros no tenemos ese tipo de problemas. Lo que necesitamos es un analista de negocio"

  "Yo ya tengo un equipo completo, y pasan varias horas al día trabajando en modelos muy complejos"

  "Ni siquiera tienen tiempo para responder las preguntas básicas que yo tengo."

  "Tengo una hoja de cálculo llena de preguntas que quiero responder"

  (Al ver la hoja de cálculo, hay cosas como esta)

  "Comparar la tasa de conversión de clientes cuyo ticket se resolvió dentro de 1 hora frente a los que se resolvieron después de 1 hora, segmentando en intervalos de $100 dólares de monto de pedido"

  (Cuando pregunto por el modelo)

  - Parece que hay que copiarlo en la pestaña correcta y con el formato adecuado dentro de una Google Sheet compuesta por innumerables VLOOKUPs

  - Los datos se actualizan todos los días, y según la salida del modelo se determinan las prioridades del equipo para ese día

  - También están calculando en hojas de cálculo los pagos a proveedores (vendors)

(Me voy a casa y me sirvo un vaso bien lleno de whisky...)

[ ¿Qué fue lo que pasó? ]

• Esto es básicamente una descripción (algo cínica) de lo que ocurre en muchas empresas al inicio de su etapa de madurez de datos

• Falta de datos y datos fragmentados

  → Muchas veces los datos simplemente no existen desde el principio porque el producto no está bien instrumentado

  → Fragmentación del sistema de datos, con información dispersa en varios sistemas

  → Procesos de negocio frágiles que operan de forma data-driven pero con muy poca o ninguna automatización

• Expectativas poco claras sobre cuál es el trabajo del equipo de datos

  → Data scientists contratados para hacer R&D y desplegar AI, pero al final sin objetivos de negocio claros

  → El equipo de datos se queja de que es difícil llevar ML a producción, pero al equipo de producto en realidad no le importa mucho esa funcionalidad

  → Personas que necesitan un "traductor de English-to-SQL"

• Equipo de producto sin formación data-driven

  → Los product managers no ven los datos como una herramienta para construir mejores funcionalidades

  → Falta de alineación entre lo que el equipo de producto quiere construir y lo que tiene el equipo de datos

• Una cultura que, en esencia, choca con una cultura centrada en datos

  → Una cultura que celebra el shipping, no el progreso medible ni el aprendizaje

  → Incluso los equipos que sí usan métricas lo hacen de forma inconsistente, miden mal y, en algunos casos, entran en conflicto con otros equipos

• Ausencia de liderazgo de datos

  → Una organización de datos fragmentada, con distintos perfiles de datos reportando a varias áreas distintas

  → Como otras áreas no reciben la ayuda que necesitan, terminan contratando muchos analistas alrededor del equipo de datos

  → Falta de estandarización de toolchains y mejores prácticas

(Vaya, esto es deprimente. ¿Qué habría que hacer para resolver este problema?)

8 de julio

• A partir de la semana siguiente empiezo a definir una nueva dirección para el equipo de datos

• Como una persona parece tener experiencia en infraestructura, le pido que construya un data warehouse centralizado

• Por ahora solo necesitamos la ruta más rápida para reunir los datos en un solo lugar

• El plan básicamente es hacer un dump de la DB de producción al data warehouse cada hora

• También se pueden enviar logs masivos de eventos desde el framework que usa el frontend para tracking publicitario, pero eso lo dejamos como deuda técnica

• Junto con el equipo de reclutamiento, definimos un Generalist Data Role

  → Enfatizamos habilidades clave de software, pero también una actitud generalista (de hacer de todo) y la capacidad de empatizar profundamente con las necesidades del negocio

  → Por ahora eliminamos toda mención a inteligencia artificial y machine learning

• Paso tiempo con otras personas de datos que no reportan al equipo de datos

  → El data scientist del equipo de marketing era una persona joven. "Siempre quise ser data scientist. Quiero aprender mucho de ti"

• Le pregunté a un amigo que dirige un coding bootcamp si tenía un buen "curso de capacitación en SQL", me dijo que sí, así que decidimos implementarlo a finales de este mes

• Preparé una presentación para el equipo de producto explicando qué es el A/B testing y cómo funciona

  → Mostrando muchos ejemplos de pruebas con resultados inesperados,

  → y la hice interactiva para que pudieran adivinar qué versión ganó

• Reunirse con la asistente del CEO para averiguar qué métricas “le gustaría que se reportaran a través de un correo automático semanal”

• Al hablar con los analistas de negocio del equipo de Supply Chain, resultó que eran personas razonables, pero habían quedado dolidos por conversaciones previas con el equipo de datos

• Uno de ellos había usado SQL en el pasado. Al verlo hacer preguntas sobre la tasa de conversión, se le dio acceso al data warehouse

• Configurar reuniones 1:1 semanales con personas de toda la organización que necesitan datos

→ El punto es encontrar brechas (gaps) y oportunidades de datos y pasarlas a los data scientists

→ Los data scientists pueden sentirse decepcionados porque sus prioridades de investigación se van postergando

→ Decirles “enfoquémonos en entregar valor de negocio lo antes posible”, pero también “quizá pronto podamos volver a trabajar en temas de machine learning. Ya veremos”

1 de septiembre: mañana

• Después de 3 meses, ya empieza a sentirse que las cosas van tomando forma

• Con reuniones 1:1 semanales con distintos stakeholders, se siguen encontrando puntos ciegos y oportunidades donde los datos pueden generar cambios

• Usar lo encontrado para empujar trabajo clave de plataforma

• Para crear datasets “derivados” hay que construir muchos pipelines. El costo inicial es alto, pero una vez que se crea el dataset correcto, los análisis posteriores se vuelven mucho más fáciles

• Empezar a abrir el acceso al data warehouse a otros departamentos

• Empiezan a hacer análisis básicos directamente con SQL

→ Algo excelente: una product manager junior descubrió que la tasa de conversión en iOS Safari era terrible. Era un bug de frontend relacionado con localStorage y se arregló con una sola línea

• El responsable de Supply Chain manda un correo enojado

→ porque cambió la base de datos y su query de 500 líneas dejó de funcionar...

→ Se le encarga el arreglo a un data scientist que se queja y se le ofrece otra zanahoria: “para fin de mes te consigo un problema interesante de machine learning”

1 de septiembre: tarde

• El product manager del equipo de checkout todavía no está haciendo análisis de métricas

• El data scientist del equipo de marketing habló con su manager y decidió reportarme directamente a mí

[ ¿Qué está pasando? ]

• Se está armando la base mínima para lo más urgente

→ hacer que los datos importantes se puedan consultar en un solo lugar

→ abrir el acceso a SQL y hacer que otros equipos lo usen, eliminando mucho trabajo de “traducción de SQL”

• Por otro lado, otros equipos podrían querer ir demasiado lejos con esta libertad. Se podría evitar poniendo permisos sobre el acceso a datos, pero eso tiene más desventajas

• El equipo de checkout no hacía análisis de datos porque no sabía a quién debía preguntarle

• Esto es, sobre todo, un problema organizacional

→ los equipos no saben cómo colaborar con el equipo de datos

→ puede que no se den cuenta, pero el equipo de datos también podría ser el cuello de botella

• Lo más razonable es “centralizar el reporte y descentralizar la gestión del trabajo”

→ porque los datos y las decisiones generan ciclos de retroalimentación más estrechos

→ para que los miembros del equipo de datos puedan colaborar dentro de cada equipo y reportarme solo a mí (líder del equipo de datos)

2 de septiembre

• El equipo de datos crece a 6 personas

→ 1 persona para la infraestructura del data warehouse

→ 5 personas asignadas a equipos distintos: onboarding, Supply Chain, checkout, marketing, y apoyo al CEO más materiales de presentación para inversionistas/directorio

• Explicar el cambio a toda la empresa y dejar claro con quién debe trabajar cada uno para sus necesidades de datos

• En adelante, aunque se contrate más personal de datos, el plan es asignarlo a otros equipos

3 de enero

• Uno de los data scientists decide irse. Como tampoco había mucho trabajo que le resultara disfrutable, se decide no retenerlo

• En el equipo hay muchas personas nuevas. Gente con algo de conocimiento de software engineering, SQL y ganas de encontrar cosas interesantes en los datos

→ como son personas que buscan “primicias” en los datos, pienso en ellos como “periodistas de datos”

• En el caso del miembro que trabaja con el equipo de onboarding

→ descubrió que en el flujo de onboarding se pedía la dirección del cliente aunque no era necesaria

→ al quitar eso, la tasa de conversión subió 21% en un test A/B

→ no fue fácil porque se necesitó trabajo de ETL para que los datos fueran fáciles de consultar, pero Python ayudó un poco y se logró

• Reporte trimestral con el CEO

→ En una iniciativa de crecimiento, un PM presenta el rediseño recién lanzado de una landing page

→ El PM enfatiza que 20 ingenieros están haciendo horas extra para cumplir con la fecha límite

→ La CMO también está muy involucrada porque tiene grandes expectativas puestas en Direct Mail como parte de este rediseño

→ Pregunta del CEO: “¿Cómo van las métricas ahora? ¿Bajó el costo de adquisición de clientes?”

(tú esperabas que el CEO hiciera esa pregunta, así que sonríes cuando efectivamente aparece)

→ El PM muestra que sí se hizo un test A/B y enseña los números en el apéndice

→ Algunas métricas suben y otras bajan, así que no hay resultados significativos; además, el costo de adquisición de clientes se ve mal

→ La CMO enfatiza que los números aún se están formando y que este tipo de campañas puede tardar varios meses

[ ¿Qué está pasando? ]

• La buena noticia es que el equipo de producto ya empezó a hacer tests A/B

• La mala noticia es que se ignoran los resultados y los proyectos en su mayoría avanzan para cumplir hitos y deadlines artificiales

• La mejor noticia es que el CEO está empujando a que cada equipo use los datos como fuente de verdad (truth)

• A medida que la organización recibe más presión para volverse data-driven, el equipo de datos tiene que acelerar la forma en que colabora con otros equipos

• En especial, la alta dirección se enfocará cada vez más en las métricas, y es tu trabajo lograr que el equipo de datos trabaje sobre esas métricas

• Una forma muy simple de hacerlo es asegurarte de que cada equipo tenga dashboards sobre las métricas que considera importantes

1 de abril

• Los antiguos trabajos de machine learning que había hecho el equipo de datos siguen ahí

• El data scientist que trabaja en el equipo de producto de inventario se interesa por el trabajo previo del sistema de recomendaciones

• Uno de los nuevos miembros contratados es un generalista, así que convirtió el notebook del sistema de recomendaciones en una pequeña app de Flask y la desplegó internamente

• Al product manager del equipo de inventario le encanta cuando la ve: “¿cómo desplegamos esto?”

• Una de las métricas clave del equipo de inventario es el “monto promedio por pedido”, y se cree que esta recomendación podría mejorarla mucho

• Incluso con una estimación rápida, parece difícil desplegarlo a gran escala, pero surge la idea: “¿y si lo desplegamos solo para el 1% de los clientes?”

• “Es medio tonto, pero si generamos por adelantado los productos recomendados con un Cron Job, creo que se puede hacer en unos días”

• Trabajando con el equipo de Supply Chain, aparecen más queries enormes en SQL

• Siguen rompiéndose, pero el equipo de datos está convirtiéndolas en pipelines adecuados

• La jefa del equipo de Supply Chain pide contratar más data scientists

[ OK, ¿qué está pasando aquí? ]

• Primero, apareció una esperanza de hacer trabajo interesante de machine learning

• El equipo de producto por fin está entusiasmado con lanzar el sistema de recomendaciones como una prueba pequeña

• Antes no se podía avanzar porque al equipo de product engineering le costaba predecir el trabajo, no quería contribuir directamente, y el equipo de datos no tenía las habilidades para llevarlo a producción

• Lo que resolvió esto fue que el equipo de datos efectivamente construyó un demo. Eso no solo lo acerca a producción, sino que también deja mucho más clara la posibilidad

• Otra cosa es lo que está ocurriendo en el equipo de Supply Chain

→ empezaron con sus propios “analistas de negocio”, pero para obtener datos necesitaban que el equipo de datos ejecutara las queries

→ los analistas empezaron a ejecutar queries por su cuenta con ayuda del equipo de datos

→ Primero, empezó a eliminar la "deuda técnica en la sombra" (consultas SQL monstruosamente grandes) que había generado fricción con el equipo de datos

→ El equipo de datos empezó a integrarse con el equipo de cadena de suministro para ayudarlo

→ A medida que miembros del equipo de datos se fueron integrando, disminuyó la necesidad de analistas de negocio y aumentó la de científicos de datos

• Recuerda que asumiste la "deuda técnica" cuando empezaste a volcar directamente la base de datos de producción en el data warehouse

• Al principio muchas cosas se rompen, pero necesitas agregar una capa que permita hacer consultas de forma estable. Puede convertirse en muchísimo trabajo

1 de julio

• Reunión de planificación del tercer trimestre

→ Antes se discutía en qué apostaría la empresa el siguiente trimestre

→ Esta vez, tú presentas las métricas principales de la empresa y cada equipo presenta cómo desglosa esas métricas principales mediante submétricas

• El trabajo del equipo de gestión de producto dio resultados

→ Los PM justifican la inversión en proyectos hablando de lo que aprendieron al ejecutar pruebas o de lo que descubrieron en los datos

• Un gran logro fue que la científica de datos que trabajaba con el equipo de checkout descubrió que, cuando el usuario presionaba el botón de volver en la página de confirmación, el objeto del carrito quedaba en un estado extraño

→ Al resolver este problema, la tasa de conversión subió mucho

• Otro insight fue que el tráfico proveniente de distintas campañas publicitarias tenía perfiles de conversión muy diferentes

→ Algunas campañas tenían un costo por clic bajo pero una conversión terrible, mientras que otras eran costosas pero tenían una tasa de conversión muy alta

• Al rastrear variables UTM y vincularlas con la creación de cuentas, fue posible medir la conversión desde el clic en el anuncio hasta la compra

→ Antes era imposible hacerlo, hasta que todos los datos se llevaron al mismo data warehouse y se normalizaron para poder consultarlos fácilmente

→ En colaboración con marketing, el KPI principal pasó a ser el costo de adquisición de clientes de punta a punta, no el costo por clic

• Otra noticia interesante es que una prueba del sistema de recomendación con el 1% fue excepcionalmente exitosa

→ Escalarlo al 100% de los usuarios es un proyecto muy grande, pero el CEO lo aprobó

• No todos los resultados fueron positivos, y muchas pruebas fracasaron.

→ Una de las diapositivas explicaba una prueba en la que el costo de envío no se cobraba por separado, sino que estaba incluido en el precio

→ El CEO dijo: "¿Qué aprendimos aquí?"

→ Esto llevó otra vez a una conversación para planificar una serie de experimentos de seguimiento

(Te vas a casa y descorchas el champán)

[ ¿Qué fue lo que pasó? ]

• Lo lograste.

• Transformaste a la organización en una verdadera nativa de los datos.

• El equipo de datos trabaja de forma multifuncional con distintos stakeholders.

• Los datos y los insights se usan en la planificación, y los datos se utilizan para generar valor de negocio, no para investigaciones con objetivos poco claros.

• La empresa usa ciclos rápidos de retroalimentación basados en datos para trabajar de forma iterativa, en lugar de grandes planes estilo "waterfall".

• Las métricas se definen de una manera que permite generar valor de negocio y asumir responsabilidad sobre él.

• La cultura de datos es impulsada en conjunto desde arriba (por el CEO) y desde abajo (por los empleados).

• Si al menos aprendiste algo, está bien fracasar.

(Felicidades. Te ganaste esa copa de champán)

[hangnim]

Al leer la primera parte, pensé que estaban hablando de mi empresa,,,, T_T (aunque nosotros ni siquiera tenemos equipo de datos jaja)

[dajoa]

Lo leí con mucho gusto. ¡Gracias~!

[shawn]

Se siente como ver un episodio de algún drama sobre startups tecnológicas que a los ingenieros les encantaría ver. ¡Está muy divertido! 👍

[hangnim]

22222

[laeyoung]

Parece que hay mucha gente, pero este tamaño ya se considera de etapa media.

[xguru]

Probablemente la escala que se maneja sea un poco distinta de la que se ve en el país.

[xguru]

Es difícil traducir de forma clara el término sesgado (Opinionated)*, pero yo suelo usar “sesgado” en el sentido de que “refleja la propia opinión y, por eso, es sesgado”.

Si quieren profundizar en esto, pueden consultar el texto que escribió otra persona:

• El significado de opinionated (sesgado) como término informático https://www.clien.net/service/board/cm_app/13558026

Además, el texto original está redactado de forma más desarrollada, pero lo reorganicé en un tono conversacional para que fuera un poco más fácil de leer.