¿Eres un 5x o 0.1x Product Manager?
Reflexiono sobre lo que hace que un PM sea un muy buen Product Manager, y lo que hace que ralentice a su equipo siendo realmente un Project Manager.
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.
Ayer desayunamos Omar Pera (VP AI Product en Freepik) y yo en La Recova, un sitio típico y muy original de Málaga. Nos debían mirar raro mientras hablábamos de las diferencias entre los buenos y malos Product Managers. En un momento del desayuno, Omar me dijo:
Yo al final creo que los Product Managers, o multiplican 5x el impacto de su equipo o lo hacen un 0.1x. No hay puntos intermedios.
Me gustó la reflexión. Creo que refleja muy bien lo que está pasando este último año en el sector. Justo ayer, otras dos personas de producto de Málaga me preguntaron qué opinaba yo sobre los despidos en PMs y los movimientos que ha habido en este último año.
Mi respuesta va muy en la línea de la reflexión de Omar. Lo que veo es que:
Muchas personas tienen el rol de Product Manager pero no están haciendo Producto, son realmente Project Managers; y en muchos casos están ralentizando más que acelerando al equipo.
Muchas empresas, y CEOs, no creen realmente en empoderar a sus equipos de producto e ingeniería. El CEO o los equipos de ventas y operaciones dicen lo que esos equipos tienen que hacer, y estos ejecutan sin pensar en el impacto.
La mayoría de equipos de producto se dedican a lanzar funcionalidades, sin medir su impacto ni iterar. La supuesta falta de tiempo para medir y la siguiente funcionalidad es normalmente la excusa.
Desarrollo mi reflexión.
1. Product Project Managers
Voy a ser crudo. Si el PM consigue que su squad mejore métricas de negocio y producto constantemente, entonces si es un Product Manager. Es o está en el camino de ser ese 5x PM del que hablaba Omar. Si no, posiblemente no sea necesario en el equipo. Ese PM es realmente un Project Manager y con excepciones, las tareas que haga las podría hacer otras personas de su equipo.
Si eres Product Manager, debes mejorar de forma clara las métricas de negocio y de producto. Tu tarea no es lanzar funcionalidades, ni captar requisitos, ni hacer el roadmap, ni definir la solución ni escribir user stories. Tu objetivo es mejorar métricas de negocio y de producto. Debes detectar bien las oportunidades y ayudar al equipo para que lo consiga. Para ello, los Product Managers deben saber del negocio incluso más que la gente de negocio.
En mis entrevistas a candidatos de producto, veo a mucha gente muy lejana de esta forma de trabajar. En una entrevista reciente fui incapaz, y eso que fui explícito, que un candidato senior me hablara en términos de negocio. Cuanto más senior seas, más negocio debes hablar.
Si preguntas a tu equipo, ¿cuántos te dirían que has multiplicado 5x su impacto? ¿cuántos te dirían que les ralentizas con PRDs y reuniones? Si estás fuera varias semanas, ¿en qué se nota en tu equipo? Sé realista contigo mismo, ¿eres Product Manager o Project Manager?
Muchos CEOs y líderes se han hecho esa pregunta y no ven clara la respuesta en muchos casos. De ahí vienen muchos de los despidos y críticas a la figura de PM. Los Engineering Managers ya pueden hacer de Project Managers. Sin embargo, los fundadores deben ser realistas. Hay mucha gente nueva en el sector de Product Management, que no ha tenido buenos mentores de producto. Muchos CEOs y fundadores cometen un gran error cuando contratan y esperan que la gente trabaje de 10 de forma inmediata. Antes, hay que formarles en el negocio y en producto y acompañarles en su crecimiento.
Os dejo un consejo, que otro día desarrollaré, el producto digital es una de las maneras que tenemos en Producto para mejorar esas métricas. Podemos conseguir incluso mejores resultados si cambiamos procesos del equipo de ventas u operaciones, si les enseñamos a usar mejor las herramientas, si les cambiamos la forma de pensar, si les enseñamos la propuesta de valor mejor, etc. Tu scope como PM no es solo el producto, debe incluir el servicio completo. En Ontruck tuvimos infinidad de ejemplos de cambiar procesos o enseñar diversos temas a gente de operaciones.
Ayer una persona que trabaja en un e-commerce con tiendas físicas me contó que lanzaron un experimento para vender y recoger en la tienda en 2h. Sin embargo, el experimento fue inicialmente un fracaso porque los dependientes no se enteraban de los nuevos pedidos. Los clientes llegaban y el pedido no estaba preparado. Es un muy buen ejemplo de no haber diseñado el servicio completo. El scope del equipo de producto debe ser tanto los productos digitales, como los procesos de los equipos.
2. Los fundadores no creen en Producto
Esto sucede todavía mucho en España desgraciadamente. Todos los emprendedores se suben a la ola de tener equipos de producto, con squads completos, pero realmente no creen en empoderar a sus equipos. Inicialmente puede que sí compren el discurso, pero cuando empieza a haber problemas – y sobre todo si los PM son realmente Project Managers – cambian al modo "se dice lo que digo yo".
Hay muchas maneras de crear una empresa exitosa, no hace falta aplicar la metodología de Producto. Hay ejemplos claros de empresas exitosas lideradas por los fundadores, donde ellos dicen; y los equipos ejecutan. Yo no critico que tengan ese modelo. Simplemente creo que reduce las probabilidades de éxito, les hace ser cuello de botella y no crean una empresa sostenible. Pero es posible que la empresa crezca con el founder trabajando 24h, y la venda. Ahora bien, una vez el fundador se vaya, va a dejar un gran agujero porque el equipo no es independiente.
Esto ha sucedido en varias startups españolas que se han vendido. Los fundadores se han ido tras su periodo de vesting y el equipo de Producto se ha quedado huérfano de liderazgo. No se había invertido en crear liderazgo de producto, ni en crear equipos empoderados de producto.
Lo único que diría a esos fundadores es que sean honestos con ellos mismos y con el equipo. Es mucho mejor ser transparente de cómo quieres trabajar; te alinea mejor con todo el mundo. En vez de buscar Head of Product o Product Managers, puedes tener Engineering Managers o Project Managers que ejecuten los proyectos que tienes en la cabeza. Si dices que buscas Product Managers, estás engañando a los candidatos, creando mucha frustración a ambas partes. Lo mismo sucede con Product Designers; si no están hablando con usuarios y solo están diseñando soluciones, entonces serán UX/UI Designers. Si eres fundador y estás frustrado o tienes dudas con este tema, escríbeme y hablemos.
Si quieres trabajar en una empresa que cree en producto de verdad, mi recomendación es que durante el proceso de entrevistas o tras la oferta que te hagan, preguntes claramente como trabajan. Profundiza en lo que te digan con los últimos ejemplos de funcionalidades.
Por cierto, una de las ideas que tengo es crear una base de datos de cómo trabajan el producto las diversas startups de España. Es una idea complicada porque requiere validar bien las referencias y la situación suele cambiar. Pero creo que ponernos frente a un espejo, nos puede ayudar a mejorar como trabajamos, ser más honestos al buscar candidatos, aportar más transparencia al sector y reducir la frustración general. ¿Cómo lo ves?
3. Foco en lanzar, sin medir ni iterar
Tras haber dado clase de Product Analytics a más de 150 profesionales, veo claro los diversos perfiles de profesionales y de empresas en este aspecto:
Hay empresas que no dan acceso a los datos a sus equipos, y no invierten prácticamente en herramientas de analítica. Los profesionales tienen muy poco margen aunque quieran ser analíticos. Les cuesta sacar datos, y no se usan para tomar decisiones. Deben conseguir que se invierta en Data.
Hay otras que invierten poco en Data; los profesionales tienen que buscarse la vida. Herramientas como Amplitude o PostHog les ayudan parcialmente. Si el profesional no sabe mucho de analítica y SQL, no sacará datos de manera frecuente. Deben formarse para ser más independientes mientras consiguen que se invierta más en Data.
Y hay otras que si son transparentes con los datos e invierten en equipo de Data y herramientas de analítica. Suelen tener una cultura fuerte de métricas. Los PMs deben formarse para estar a la altura de lo esperado.
He comentado anteriormente que los Product Managers deben conseguir que su squad mejore métricas de negocio y producto constantemente. Es una obviedad, pero para conseguir eso, hay que medir e iterar las funcionalidades.
Si lanzas una funcionalidad, y ni mides ni coges feedback de tus usuarios, no sabrás que tal funciona ni que impacto estás generando. Me contaba un profesional que lanzaron una funcionalidad nueva que tenía muchos Daily Active Users. Sin embargo, no medían conversión a pago, ni satisfacción de usuario ni recurrencia de esa funcionalidad. Cuando ya por fin empezaron a medirlo, se dieron cuenta de que la satisfacción del usuario era solo de 4/10, tenía poca conversión y poca recurrencia. Se pusieron las pilas, iteraron la funcionalidad con el feedback de los usuarios y consiguieron subir la satisfacción a 8/10, y por tanto aumentó la conversión a pago y recurrencia. Un gran cambio de apenas unas semanas.
Debe ser obligatorio medir cuando estás construyendo una nueva funcionalidad. No es una user story que ya haremos. No son datos que guardamos que ya miraremos. Ingeniería debe implementar los eventos cuando desarrolla la funcionalidad. La Product Manager o Data Analyst debe sacar los datos unos días después de lanzar la funcionalidad, y debe compartir con su squad y con la empresa qué tal ha ido. ¿Habéis conseguido lo que queríais?
Si no mides, no busques excusas fuera. Vosotros mismos en el squad podéis lanzar eventos usando herramientas gratuitas y sacar conclusiones. Los ingenieros pueden hacer queries a la base de datos de producción. No necesitáis el ok de nadie. Podéis hacerlo aunque os digan que no hace falta.
Otro tema es la falta de foco que suele haber. En cuanto terminamos una funcionalidad, ya tenemos otro foco que atender. En muchos casos la estrategia del CEO es hacer todo, no quiere elegir. Si podemos hacer todo, ¿por qué no? La realidad es que si haces todo, tienes altas probabilidades de crear un peor producto con un churn alto y vas a descuidar lo que realmente te hace único. Hay muy pocos casos de productos que hayan triunfado con la estrategia de tener todas las funcionalidades de su sector. Lo más común es que crezcas siendo muy bueno en una cosa.
Mi feedback a esas personas que no dejan espacio para iterar es que si invertimos 1-3 meses en hacer una nueva funcionalidad, conseguimos quizás el 50% del potencial impacto. Si invertimos algunas iteraciones más, con el esfuerzo bien dirigido según entendamos el feedback de los usuarios y las métricas, conseguiremos acercarnos al 90% del potencial impacto. Debes descubrir primero si la funcionalidad cumple su objetivo y qué iteraciones nos darán ese extra impacto sin demasiado esfuerzo.
Esta forma de trabajar de lanzar funcionalidades en distintas áreas nos aleja de generar impacto en métricas de negocio y de producto. Es imposible tener tantos focos. Te hago las siguientes preguntas: ¿cuánto has incrementado el revenue de tu empresa este año? ¿o cuánto has reducido sus costes? ¿cuánto has mejorado la satisfacción de tus clientes y usuarios? No te debe importar las funcionalidades que has lanzado, te debe importar el impacto que tu trabajo genera.
Si eres un manager y quieres provocar ese cambio de mentalidad, mi recomendación es que enfoques al equipo en 1-2 objetivos y empieces a hablar de métricas de negocio y de producto en tus one-on-one, reuniones del equipo, comunicaciones con la empresa, updates de producto, demos, etc. No preguntes por el status de cada funcionalidad, pregunta por el impacto generado. No cuentes que se ha lanzado, comparte qué métricas habéis mejorado. El impacto es lo que importa.
Concluyo con unas preguntas que me gustaría que pensaras y me respondieras a este email si te animas:
Si ya multiplicas 5x el impacto de tu squad, ¿qué es lo qué más te ayuda a conseguirlo?
Si no, ¿Qué te falta como PM para multiplicar 5x el impacto de tu squad?
En general, ¿Qué ralentiza a tu squad?
Excelente post, lastimosamente existen muchas estructuras donde no permiten que producto cumpla con su rol para simplemente acompañar la ejecución.