¿Cómo sería un muy buen equipo de producto sin PMs?
Las poco acertadas palabras del fundador de Airbnb ha traído una avalancha de reacciones, pero, ¿es posible? ¿y cómo sería ese equipo?
Te animo a echar un vistazo a los cursos que acabo de abrir para Mayo:
Fundamentals of Software Engineering si quieres tener una base técnica para trabajar mejor con ingeniería; puedes hacerlo a tu propio ritmo. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Fundamentals of Product Analytics si quieres empezar a ser analítico, empezando a analizar datos y definir KPIs y funnels. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Advanced Course in Product Analytics si quieres aprender a hacer análisis avanzados y conectar métricas de negocio con producto. La octava edición comienza el 30 de abril.
Advanced Course in Product Engineering si desde ingeniería o datos quieres acercarte a negocio y producto. La cuarta edición comienza el 30 de abril.
Las declaraciones de Brian Chesky, fundador y CEO de Airbnb, en una reciente conferencia de Figma han desencadenado un torrente de reacciones. Chesky sugirió que habían eliminado el rol de PM en Airbnb, pero se retractó casi inmediatamente, aclarando que en realidad habían buscado potenciar a los diseñadores y fusionar los roles de Product Manager y Product Marketing Manager. Sin embargo, el rumor ya se había esparcido por las redes sociales.
Mejores prácticas vs Realidad
Mi reacción al escuchar su rectificación fue reflexionar sobre cómo los Product Managers en Airbnb parecen estar más enfocado en la gestión de proyectos que en el diseño de productos. Es interesante destacar cómo las teorías de Silicon Valley contrastan a veces con las prácticas de trabajo reales.
Recordé una visita a las oficinas de Airbnb en 2012, donde nos comentaron que contaban con cerca de 500 diseñadores. Tal cantidad me resultó desconcertante. El Airbnb de aquella época era bastante mejorable. En muchos casos, un alto volumen de personal puede generar ineficiencias importantes, dando lugar a una organización sobrepoblada de project managers.
Este escenario es otro ejemplo de la complejidad inherente al buen trabajo en producto, y de la brecha que existe entre las mejores prácticas y la realidad de las empresas. En pocas organizaciones se implementan realmente las mejores prácticas. La implementación de las mejores prácticas es una visión y un camino a recorrer, que requiere de un equipo estable y trabajo constante durante años.
La dificultad de escalar una organización de Producto
El caso de Airbnb representa un desafío monumental en términos de escalabilidad. Configurar un equipo de producto sólido y pequeño, de menos de 10 squads, resulta ser una tarea mucho más manejable que escalar a un nivel que incluye cientos, incluso miles, de PMs, Product Leads, Directors of Product Management, Heads of Product, VPs Product y CPO; sin olvidar a los numerosos PDs, PD leads, Directores de Diseño, Heads of Design, y VPs de Diseño.
Imagínate cuán alejado puede estar el liderazgo de las microdecisiones que el equipo toma diariamente. Dado su rápido crecimiento y alta rotación, es probable que las decisiones sobre el producto estén en manos de aquellos que pueden carecer de la experiencia suficiente para hacerlo de manera óptima. Y los individuos más experimentados podrían estar demasiado alejados del núcleo de la acción.
Por esta razón, cada vez soy más cauteloso al considerar un rápido crecimiento de la organización de PMs. Preferiría un ritmo de crecimiento más lento. Menos personas implica un mejor control. Cuantas menos capas de managers, mejor.
Recordando 2017, ya éramos unos 12 ingenieros y 2 diseñadores en Ontruck. Teníamos dos pseudo-squads y yo gestionaba la visión, establecía las prioridades, trabajaba con los diseñadores en cada detalle y acordaba el enfoque y el alcance con ingeniería. Trabajaba muchas horas, pero al tener menos personas, las decisiones fundamentales eran más sencillas y rápidas de tomar. Esperé tanto como pude antes de contratar al primer Product Manager.
La importancia de tener ojo de halcón en el liderazgo de producto
En su ya conocida charla, Brian menciona que ahora todas las decisiones de producto pasan por él y su equipo de liderazgo. Desconozco cómo está funcionando realmente, pero lo que sí sé es que resulta arriesgado que los líderes se distancien de las decisiones relativas al producto. Delegar no significa abandonar. Puedo tener plena confianza en alguien, pero también soy consciente de que esa persona puede necesitar feedback, puede carecer de contexto de negocio, o bien, que directamente deseo que se siga mi visión de diseño del producto. Si solo gestiono OKRs e informes, no estoy verdaderamente inmerso en el producto. Si quiero estar verdaderamente inmerso en el producto, es esencial que esté trabajando codo a codo con los product managers y con los diseñadores en Figma.
En Ontruck, llevábamos a cabo Design Critiques todas las semanas, a las que intentaba asistir frecuentemente. Los diseñadores compartían sus diseños en Slack buscando feedback, y yo colaboraba activamente. Si algo no me convencía, me hacía un hueco el día siguiente para dialogar y buscar conjuntamente una solución mejor. Ese "algo" podía ser un texto impreciso, una manera de plantear una pantalla que no escalaría bien o una complejidad innecesaria. A medida que todo el equipo iba adquiriendo este nivel de detalle y de exigencia, mi intervención ya no era tan necesaria. Sin embargo, mi ojo de halcón permanecía atento. Si algo pasaba y yo lo veía, lo señalaba para discutirlo y mejorarlo.
Un producto es algo muy delicado. Puede tener una base muy sólida, pero si se comienzan a tomar varias decisiones semi-incorrectas, la experiencia del usuario puede empezar a fracturarse. Por lo tanto, es esencial estar siempre atentos, buscando siempre la excelencia. Eso solo sucede si es una prioridad real del liderazgo, una de esas prioridades en las que inviertes tiempo todos los días.
Por lo tanto, resulta muy arriesgado escalar una organización de producto con numerosas capas intermedias. Es crucial hacerlo de manera óptima, con profesionales de alto calibre y un alto nivel de detalle para asegurar que las decisiones de priorización y diseño del producto sean las mejores. No son tantas las personas que poseen la capacidad y actitud necesarias para mantener siempre ese ojo de halcón.
Entonces, ¿cómo sería un muy buen equipo de producto sin un PM?
La respuesta es... un equipo de producto empoderado. Este sería un equipo en el que:
La líder de producto o de ingeniería identifica y establece las prioridades de alto nivel.
La Engineering Manager y el Diseñador de Producto traducen estas prioridades en objetivos y alcances concretos para el ciclo.
El Diseñador de Producto investiga junto con el negocio y los usuarios, propone el enfoque y diseña en colaboración con los ingenieros seniors del equipo.
La Engineering Manager trabaja con su equipo para asegurar que todas las propuestas estén bien definidas desde una perspectiva de ingeniería antes de comenzar a programar. Se coordina con el Diseñador de Producto para alinearse con el negocio e iterar objetivos y alcances a medida que adquieren nuevos conocimientos.
Los Ingenieros de Producto lideran iniciativas, diseñan junto con el Diseñador de Producto, escriben sus propias User Stories, programan sin la necesidad de que alguien más realice el QA y suben los cambios a producción en coordinación con negocio.
Me acuerdo ahora de una frase que le dije a los PMs de Citibox hace unos meses, “vuestro objetivo es que no seáis necesarios”. Y efectivamente, si el resto de piezas funciona perfecto, un PM no es tan necesario en el día a día. Lo cual es perfecto, porque le genera espacio para hacer de verdad Product Discovery. Cuanto más tenga que estar en todos los pasos anteriores, menos hará.
Esto es algo que me resulta fácil de describir porque lo hemos experimentado en varias ocasiones en Ontruck. Hace un par de años, una PM de mi equipo estuve de baja de maternidad y yo la cubrí. Como el equipo ya estaba funcionando de manera eficiente y los objetivos estaban claros, solo tenía que invertir unas 4 horas a la semana. El equipo operaba de forma autónoma. Yo podía centrarme en la estrategia a 3-6 meses.
En este momento, Ontruck se encuentra en esta situación. Tienen unos 10 ingenieros de producto, 2 diseñadoras de producto, un engineering manager, 2 analistas de datos, pero no hay un PM. El CTO y el CSO trabajan con el equipo para definir los objetivos a alto nivel, y entre ellos aclaran, concretan las necesidades y ejecutan.
Esta situación de no tener un PM puede darse si todo el contexto alrededor lo facilita. Si el equipo de ingeniería no se hace cargo de la ejecución, se requiere un PM con habilidades de gestión de proyectos. Si no está claro cuáles son las siguientes prioridades, se necesita un PM que haga ese trabajo y proponga. Si estamos en modo de expansión y hay que descubrir nuevas oportunidades, se necesita un muy buen PM que realice ese descubrimiento y traiga oportunidades. Si hay que coordinarse con los clientes, se necesita un PM que hable con ellos y proponga un roadmap. Si el Diseñador de Producto es junior o mid-level, se necesita un PM con experiencia que le ayude a tomar mejores decisiones de producto. Si no hay un Analista de Datos, se necesita un PM que analice los datos de comportamiento, extraiga conclusiones y tome decisiones.
Hay una reflexión que todavía no he leído a nadie hacer y me parece aún más relevante que la pregunta de si los PMs son necesarios. ¿Están los diseñadores de tu empresa realmente preparados para ser Product Designers con voz en la mesa de decisión? ¿Vuestros líderes de ingeniería son personas que piensan en negocio y en producto? ¿Están listos vuestros desarrolladores para ser Product Engineers responsables del end-to-end de una funcionalidad? Porque la única manera de que los PMs no sean necesarios, es que el resto del squad crezca y asuma todas esas responsabilidades.
Conclusión
Aunque el papel de un PM puede ser vital en muchos contextos, hay situaciones donde es posible que un equipo autónomo y eficiente pueda funcionar sin uno. Lo crucial es que las decisiones fundamentales del producto estén en manos de personas con el conocimiento y la experiencia adecuados, y que todo el equipo esté alineado y comprometido con la visión del producto. La estructura de un equipo de producto no tiene una única solución correcta; la clave está en encontrar el equilibrio que mejor funcione para tu organización en el momento en el que está.
Os dejo tres artículos que he escrito sobre crear equipos empoderados:
Muy buena reflexión, aunque por mi experiencia pocas empresas están en condiciones de prescindir de un PM. No solo es que los equipos de diseño y de desarrollo asuman esas responsabilidades, sino que el propio ecosistema, los stakeholders realmente tengan esa misma cultura, que los procesos de la empresa estén ordenados y la demanda se haga de manera controlada y efectiva, y además, si esos equipos se responsabilizan de esas tareas, dejan de hacer otras.
En el ejemplo en tu empresa, al final se reparten las responsabilidades pero siguen existiendo y vienes de un estado controlado, y aunque estoy de acuerdo con que es el objetivo final del PM es empoderar a los equipos, su figura es necesaria para mantener a lo largo del tiempo ese modelo y esa cultura, sino en 1 o 2 años, seguramente volverá a funcionar como pasa en muchas empresas. Caos y fallos porque nadie se responsabiliza del end to end.