Aprendiendo en Product Tank Madrid de Javier Querol, CPO de Mercadona Tech
En la primera charla de Product Tank Madrid en más de un año Javier Querol, CPO de Mercadona Tech, nos explicó cómo Mercadona Tech pudo escalar los equipos de producto sin morir en el intento
Mi nombre es Alex Swiec y cada semana os comparto ideas y aprendizajes que me han ayudado en mi carrera profesional construyendo producto digital.
Si quieres seguir aprendiendo conmigo, suscríbete y cada Sábado a las 7am recibirás una nueva píldora de aprendizaje que espero te permita ser mejor product manager.
Esta semana os comparto lo que yo aprendí del evento de Product Tank Madrid, que organizamos junto con Fernanda Sozinho en las oficinas de Mercadona Tech.
Además de la charla, fue bonito poder re-conecatar como comunidad, compartir charlas e impresiones después de la charla de Javier Querol y conocer a otros product managers con diferentes backgrounds y experiencias.
Os dejo el enlace de la página oficial de Product Tank Madrid por si quieres estar informado de próximos eventos que organizaremos en el futuro.
Página Meetup de Product Tank Madrid
TL;DR
En la última charla de Product Tank Madrid, nos compartió Javier Querol cómo en Mercadona Tech empezaron con un único equipo de producto, que estaba enfocado en la página de e-commerce, y poco a poco fueron escalando los equipos de producto para abarcar diferentes funciones como gestión de pedidos en la “colmena” y el “delivery” de los pedidos.
Nos contaba Javier que el reto más grande a medida que los equipos de producto crecen es la comunicación, y es por eso es necesario estandarizar dicha comunicación.
Además de la estandarización de comunicaciones, Javier nos explicó que es importante la correcta alineación entre equipos mediante la creación de jerarquías, así como la cada vez más importante gestión de stakeholders
Por último nos explicó cómo también es importante la creación de documentación de producto que explique de forma clara para poder tener alineamiento entre equipos, la creación de dominios en donde varios equipos colaboran para poder conseguir objetivos comunes, y por último la correcta gestión de los datos, tanto a nivel de limpieza de datos como su gobernanza.
Los principios de producto en Mercadona Tech
Javier nos contó que desde el principio, cuando había únicamente un equipo de producto, los principios de producto estaban basados en design thinking + Lean Development + Agile.
Esta es la base para poder entender bien el problema, construir la solución adecuada y desarrollar de forma iterativa para conseguir los resultados esperados.
Escalando equipos en Mercadona Tech
Nos explicaba Javier Querol que a medida que se empiezan a entender mejor los equipos, éstos se dividen en diferentes “problemas”, y cada equipo empieza a ser owner de problemas cada vez más concretos.
En este punto, el problema es de comunicación, y donde más fricción se produce es en la intersección de los equipos, y es por eso que se tiene que estandarizar para que todos los equipos se comuniquen de la misma forma y con la misma cadencia.
Y es por eso, además de escalar los equipos, Mercadona Tech vió la necesidad de escalar la comunicación ya que si cada equipo comunicara “a su manera” la comunicación sería caótica.
Escalando la comunicación
Uno de los puntos más interesantes es cómo Mercadona Tech usa la estandarización de comunicación de la siguiente forma:
Estandarización de canales Slack: Todos los equipos de producto comunican de la misma forma por los canales de slack, especialmente cuando nuevas funcionalidades se desarrollan
What’s New: Comunicar de forma clara y concisa que es nuevo, para que todo el mundo esté informado, ya que cuanto más se informa del cambio y la razón detrás del cambio, más adopción e impacto genera en la empresa.
Estandarización de creación de contenidos: Se tiene un portal de contenidos en donde los diferentes equipos necesitan entrar a revisar el contenido generado, y los supervisores de los equipos se encargan de que las diferentes personas estén formadas para entender las nuevas funcionalidades generales.
Estandarización de comunicaciones a otros equipos: La estandarización de la comunicación a otros equipos es fundamental. Equipos como customer care, soporte, transportistas u otros equipos deben estar informados con cadencia y de la misma manera consistentemente, para que dichos equipos entiendan los cambios que se están produciendo
Nos explicaba Javier Querol que a pesar de la estandarización y procesos, siempre habrá problemas de comunicación y que en cualquier caso debe haber proactividad por la parte de los equipos para comunicar a las personas adecuadas en el momento adecuado.
Aportando valor al negocio
El circulo virtuoso que se busca en cada equipo es proveer a los clientes, ya sean “jefes” (los clientes que piden por la web) como los operarios de las “colmenas” (grandes centros de empaquetado de pedidos online) para que adopten las nuevas funcionalidades, y que éstas a su vez aporten valor al negocio
Este círculo virtuoso permite hacer crecer el negocio y dar más valor al usuario final.
Cómo conseguir alineamiento
Otro punto importante de la charla de Javier Querol fue la parte de alineamiento, en donde compartió 4 puntos importantes.
Jerarquías: En cuanto a escalas, se necesitan jerarquías, lo que a su vez trae más problemas de comunicación. Pero es el precio a pagar para que los equipos estén alineados
Gestión de stakeholders: Con tantos posibles desarrollos, el arte de gestionar bien a los stakeholders para que apoyen proyectos y “abran puertas” es muy importante, ya que de ello depende la financiación y en muchos casos el éxito de una iniciativa
Product Inception Documents (PIDs): A medida que el negocio se vuelve cada vez más complejo, los product managers necesitan tener sus ideas más claras para poder comunicarlas a todo el negocio. Para ello se crea el product inception document (PID) que permite a un product manager poder bajar sus ideas a un documento que luego comparte con los departamentos adecuados, que le proporcionarán feedback muy necesario para que la iniciativa que el product manager quiere llevar a cabo sea un éxito
Dominios: Mercadona Tech tiene 14 equipos, cada uno de ellos especializado en un problema concreto. Pero la realidad es que cada problema concreto está interrelacionado con otros problemas. Es por ello que Mercadona Tech crea dominios en donde varios equipos comparten y se alinean en los desarrollos y evolución de los productos
Diferentes dominios y modelos de negocio
Los dominios que Mercadona Tech reparte sus equipos son:
Ecommerce: La parte de compra en tienda de los clientes
Colmena: Estos son los centros logísticos en donde se empaquetan los pedidos de los clientes de forma muy automatizada y ordenada y con procedimientos y pasos muy claros
Delivery: El dominio que gestiona hacer llegar a las casas de los clientes el pedido encargado
Gestión de personas: En Mercadona Tech hay muchos operarios que hacen que los pedidos lleguen a las casa de las personas, y hay también sistemas y productos para gestionar a estas personas
Tiendas: A medida que el modelo de ecommerce se expande, hay lugares en donde las colmenas no tienen alcance, y los pedidos se montan en tiendas de Mercadona
Si bien este modelo de arriba parece que está “escrito en piedra”, en la charla nos comentaba Javier Querol que este modelo está en constante evolución.
Por ejemplo, Javier nos comentaba que aunque los modelos de Colmena y Tienda son muy distintos, a medida que pasa el tiempo algunos procesos empiezan a converger, por lo que en el futuro estos dos dominios no deberían estar separados.
O dicho de otra forma, el modelo se monta sobre grandes discusiones y que a veces hay que tomar una decisión sobre cómo configurar equipos y dominios y se necesita aceptar la decision y “tirar para adelante”hasta que funcione.
Analítica y datos
En cualquier industria de grandes volúmenes, como es el caso de la industria de la alimentación, la correcta gestión de la información y el dato es fundamental, ya que permite medir de forma correcta el problema concreto que estamos intentando resolver, y también la correcta toma de decisiones.
Javier Querol nos explicó que si bien al principio se montaron los sistemas de Business Intelligence directamente encima de los modelos de datos, a medida que los volúmenes de datos crecía, se tuvo que buscar formas para eficientar el modelo para que las obtención de datos no se volviese lenta.
También, a medida que la complejidad del negocio crecía y los equipos creando producto y teniendo necesidad de consumir datos crecía, se tuvo que generar procesos de limpieza y gobernanza del dato para que las personas pudieran tener una “fuente de verdad” en donde cada equipo pudiera acceder al dato que realmente le generaba valor, y se empezase a limitar el acceso a datos que no tenían valor para determinados equipos.
Conclusiones de la charla de Javier Querol
Las conclusiones de la charla de Javier fueron muy claras y resumía muy bien todo el contenido que se compartió durante la presentación.
Aquí os dejo los puntos más importantes que compartió:
Comunicación siempre será un problema: La comunicación al crear producto siempre será un problema, y a medida que escalamos los equipos también escalamos los problemas de comunicación, por lo que hay que buscar estructuras y estándares de comunicación para minimizar el problema y mejorar la comunicación
Las estructuras facilitan la comunicación: Tener estructuras claras permite que la comunicación sea más fluída y se consiga un mejor alineamiento entre equipos. Dicho esto, hay que ser muy proactivo para que la comunicación se distribuya de forma adecuada.
Gestión de stakeholders: A medida que se crece, hay cada vez más iniciativas y problemas que resolver. Gestionar bien expectativas y conseguir apoyos de stakeholders se vuelve cada vez más crucial
Gestión apropiada del dato: A medida que se escala, se necesita tener una mejor gobernanza y acceso adecuado a los datos importantes para cada equipo
Lo importante es generar valor: Generar valor significa generar más negocio que permite seguir creciendo y mejorando los productos, y esta perspectiva no se puede perder cuando los equipos son más grandes
No quiero cerrar este post sin agradecer a Jose Ramón Perez Agûero, que fue la persona que nos abrió las puertas para que este evento pasara, a Joanna Sypniewska y Marta Lago Leal por la organización, a Javier Querol por la magnífica charla, y también a todos los asistentes de Product Tank Madrid, ya que sin ellos este evento no tendría sentido.
Como siempre digo al final de mis posts, si te gustó el contenido dale al “corazoncito” y compártelo con la gente que creas le pueda ser útil.
Por último te dejo el enlace de Product Tank Madrid por si quieres unirte a futuros eventos que organicemos
Gracias por el excelente resumen para los que no pudimos asistir!
Excelente resumen Alex!👌🏼