No permitas que los dogmas del product management arruinen tu carrera

Seguir los dogmas del Product Management a rajatabla puede hacerte sufrir a ti, a tu equipo, y dañar tu carrera profesional

Introducción

En 2013, hace ya más de 10 años, hice un curso de Product Management en General Assembly, y ahí empecé a aprender los “dogmas del Product Management”.  

Después de este curso, empecé a atender a Product Tank en Londres, y cuando volví a España lancé y coordiné Product Tank Madrid durante más de 6 años.   

La idea de la comunidad de Product Tank, que es una asociación sin ánimo de lucro fundada en Londres, es poder hacer charlas informales sobre el rol de Product Management.

En esta charlas algunos referentes en el rol de producto digital hacen una presentacion sobre sus experiencias en producto digital, y luego se genera un debate sobre lo expuesto por cada uno de los presentadores.

Pero algo extraño empezó a ocurrir. 

Lo que las personas contaban en las charlas de Product Tank Madrid y lo que alguno de estos profesionales contaban después de las charlas en las cervezas de después en ocasiones no eran exactamente la misma historia. 

Mi intención con este post es sacar a la luz el lado oscuro que esconden estos dogmas de producto que se aprenden en algunas escuelas, charlas y libros relacionadas con la creación de producto digital.

Estas teorías son buenas en determinados contextos, pero nefastas en otros.

La realidad es que a veces estos dogmas no se pueden aplicar, y que si empujas demasiado acabarás haciendo que tu trabajo y el de tus compañeros se vuelva insoportable. 

Dogma #1: No podemos dar fechas, o el dogma del roadmap “Now, Next, Later”

La idea que hay detrás del Roadmap de Now, Next, Later es que no deberíamos dar fechas porque entonces todo se convierte en delivery (entregable de funcionalidades) y no en outputs (mover métricas concretas de producto).

Esto se traduce en un roadmap del estilo de  “Now, Next, Later”.

Esto en teoría es genial porque el foco total está en el output. Pero no sé si has trabajado alguna vez con ejecutivos de empresas corporativas.

Bueno, te cuento que ejecutivos aman  las fechas, y si les dices que no les vas a dar fechas, ahí tendrás un directivo cabreado. 

Pero esto no sólo se limita a ejecutivos corporativos. Este mismo comportamiento lo he visto en Startups y Scaleups.

Y con el tiempo la verdad que entiendo el punto de vista de todas estas personas que velan por generar resultados financieros en la empresa.

Vale, es verdad que el foco está en los outputs, pero sin funcionalidades entregadas en producción, las métricas no se mueven.

Además, he comprobado que con un poco de esfuerzo, planificación y apoyo del technical lead se puede dar fechas, aunque sea en un rango de 3 meses, para poder dar un poco de luz al final del túnel para la gente de negocio.

Uno de los libros que me hizo replantearme el mantra de “nunca dar fechas” fue “The Manager 's Path” de Camille Fournier.

En este libro la autora explica que un líder técnico podría dar fechas si hace el trabajo de entender qué se quiere entregar, y se tienen en cuenta también los riesgos que se pueden dar en el proyecto para tenerlos en cuenta a la hora de dar fechas.

De nuevo, comparto 100% que el foco debe estar en el output (resultado esperado) y no en las métricas.

Pero también es verdad que la ejecución es fundamental para sacar algo al mercado y que cuanto antes salgamos, antes podremos entender si nuestra hipótesis de producto es válida o no. 

Dogma #2: El Dual Track de Discovery y Delivery

El Dual Track, primeramente definido por

Marty Cagan

, viene a decir que tenemos que tener a 2 equipos en paralelo trabajando, y que un equipo se enfoca en Discovery (entender qué quieren los clientes) y otro equipo en Delivery (desarrollar lo que quieren los clientes).

¿No vislumbras algún problema aquí?¿De verdad que no?

Bueno, te lo cuento porque a mí sí me ha pasado:

• De repente el Discovery se queda corto, y tienes que arrancar el Delivery con asunciones que están medio cocinadas.

• El equipo de Discovery descubrió un insight super bueno, pero el equipo de Delivery no lo tiene tan claro y empieza a tener dudas.

• Un Product Manager tiene que hacer Discovery y Delivery, no le dé la vida, y acaba quemándose a lo bonzo o haciendo ambos tracks a medias y de forma incorrecta.

El punto es que a veces el Dual Track no funciona y quizás haya que buscar una alternativa a este dogma sobre cómo se construye producto digital.

Y no lo digo solo yo, lo dice también Ryan Singer, que durante muchos años era Head of Strategy en Basecamp.

Ryan sacó un libro gratuíto llamado “Shape Up: Stop Running in Circles and Ship Work That Matters”, que explica como sacar producto digital “como se ha hecho toda la vida”, sin tener que iterar todo en ciclos de 1 o 2 semanas.

Lo que plantea el libro es definir un apetito de riesgo y asociado a ese apetito definir un proyecto de toda la vida para validar nuestras asunciones. 

Te comparto el video de Ryan Singer, en donde explica la metodología de Shape Up, por si quieres profundizar en esta forma de hacer producto, ya que puede darte una nueva perspectiva sobre cómo se puede desarrollar producto digital.

Dogma #3: Necesitamos datos para tomar decisiones de producto

Si, es verdad que se necesitan datos y que es importante medir bien lo que están haciendo nuestros usuarios en el día a día. 

Pero tampoco se puede ser dogmático hasta el punto de parar todo los desarrollos porque quieres instrumentar una plataforma de arriba a abajo.

En el pasado también he sido dogmático sobre este punto, y esto generó fricciones innecesarias en el equipo de producto.

Instrumentar un producto no es algo que todos tus stakeholders entenderán, y por eso el primer paso es explicar de forma clara y concisa porque es bueno para el producto, así como el impacto a medio y largo plazo de llevar a cabo esta instrumentación. 

Si consigues buy-in para instrumentar, el siguiente paso es decidir qué herramientas vas a utilizar para llevar a cabo la instrumentación de tu producto digital.

Y una vez se decida qué herramientas se van a usar para instrumentar tu producto digital, te recomiendo empezar poco a poco, para no dejar atrás a los que son nuevos en el paradigma de la instrumentación de producto.

Yendo un paso más allá, a veces tampoco hace falta esperar a los datos para tomar decisiones. A veces lo único que falta es sentido común, que en muchas ocasiones parece que es el sentido que menos usamos al construir producto digital. 

Pongo un ejemplo de mi época en Careershifters:

• En Careershifters vendíamos cursos de formación en UK, por lo que los clientes pagaban en libras esterlinas y recibían confirmación de los horarios del curso en horario GTM.

• Empezamos a ver que algunos de los clientes compraban fuera de UK (desde Europa y USA) y que sumaban un 25% del total de clientes que compraban.

Quizás no hacen faltan muchos más datos para decidir añadir la posibilidad de permitir que estos nuevos clientes pudieran pagar en dólares americanos y euros, y comunicarles el horario de los programas en el horario local en la cual serían sus llamadas. 

¡Y ya os confirmo que no, porque recibíamos muchos mails a soporte pidiendo que se clarifique el precio en Euros y Dólares, y cuándo serían las llamadas en horario CET u horario estadounidense!

A veces lo único que hace falta es sentido común, desarrollos mínimos, y ver si las métricas de básicas de registros del público objetivo aumentan.

Dogma #4: El product Trío es sagrado

El product trio busca añadir más voces a decisiones importantes de producto. 

Y esto es bueno porque si más personas entran en la ecuación a la hora de definir qué hay que construir, seguramente se creará un producto mejor que si esto únicamente lo decide una persona del equipo.

Pero como todo dogma, a veces el product trío no es suficiente porque hay otras áreas que son importantes para determinadas funcionalidades.

Por ejemplo, si trabajas en empresas que prestan servicios financieros, es muy buena idea traer al trío a las áreas cumplimiento y seguridad, porque estos equipos pueden tener restricciones que necesitas tener en cuenta desde el día uno. 

De la misma manera, quizás en algún equipo no tengas a uno de los 3 roles del product trio, y serán los otros 2 roles quienes cubran el rol que no está en el equipo.  

Dogma #5: El product manager como agente del cambio

En un post de este mismo newsletter, la teoría de lo prácticamente imposible,

Roger Serret

explica muy bien cómo cuando entras en una empresa verás muchas cosas por las que seguramente te eches las manos a la cabeza.

A veces parece que el Product Manager tiene que resolver todos los problemas del universo del producto, y que hasta que no estén todos los semáforos en rojo no se podrá hacer producto bien. 

El problema es que esto genera un nivel de estrés gigante, porque es como tratar de comerse un elefante y no sabes si empezar por la cola o por la trompa. 

Este es mi consejo: Relájate, no te pongas nervioso, respira, nadie te ha pedido que seas superman. 

La empresa a la que hayas entrado seguramente ya haya conseguido el cuasi-milagro del product-market fit.   

Cuando esto se ha conseguido quiere decir que la nave se ha levantado del suelo y está subiendo, por lo que la peor parte ya ha pasado, y ahora hay que ver que se podría mejorar para hacer más caja.

Y estás en una startup que todavía no ha conseguido market-fit, te tocará hablar mucho con usuarios y probar hipótesis, por lo que muchos de los conceptos de producto tampoco te servirán en esta etapa del producto. 

Por eso mi recomendación es que, en vez de poner foco en todas las cosas que no están bien hechas, pongas tiempo y foco en responder a esta pregunta: ¿Qué cosa no está haciendo este equipo de producto, que si lo hiciera, todo cambiaría?

No te agobies con ser “el agente del cambio”, elige bien una batalla que luchar, dedícale tiempo, y únicamente pasa a la siguiente batalla cuando este cambio se haya cimentado tanto que ya sea parte de la cultura de hacer producto.

Dogma #6: Split de equipos de producto en squads

El último dogma que quiero traer a la luz, y uno de los que más quiero resaltar, porque viene a mostrar lo absurdo de seguir los dogmas de producto, es el famoso split de equipos de producto en Squads. 

No digo que esto sea “per se” una mala práctica, pero el lado oscuro es que a veces se pierde la visión de cúal es la misión en la que se está trabajando y también genera muchas fricciones entre los equipos de producto que trabajan cada uno en “su parcela”. 

Lo gracioso de todo esto es que, Amazon, la empresa que definió que hizo famoso el mantra (y dogma) de que los equipos debían ser pequeños (¿Recuerdas el mantra los equipos y las 2 pizzas?), fue la empresa que luego tiró esta práctica a la basura porque no le funcionaba. 

Y es que su propio dogma chocaba con la realidad del día a día de la empresa, y evolucionaron a una técnica llamada “liderazgo mono-hilo”. 

Ahora Amazon pone a un líder a la cabeza de un equipo, y es este líder el que decide cómo se estructura un equipo,y en muchas ocasiones se prescinde de los famosos squads. 

De nuevo, el líder aplica el sentido común para estructurar los equipos de la forma que él crea más oportuno.

Hace poco

Simón Muñoz

escribió un post muy bueno en donde se explicaba el concepto de liderazgo (y estructuras de equipo) mono hilo, por si quieres profundizar en esta nueva forma de estructurar equipos de producto.

Nuevos dogmas que están emergiendo

Aquí te dejo algunos dogmas que veo que están emergiendo, y las precauciones que yo estoy teniendo para no caer en la misma trampa que los dogmas que ya están cimentados en la cultura de producto.

Nuevo Dogma #1: Product Operations

Tanto Melissa Perri como Marty Cagan están creando nuevas teorías (o debería decir dogmas) en 2024 en relación a la operación de producto digital.

Estos dogmas se encuentran en los libros “Product Operations”, de Melissa Perri y Denise Tilles y Transformed: Moving to the Product Operating Model de Marty Cagan.

Ambos libros ponen foco en el rol de Product Operations que vienen a “poner orden” dentro de los equipos de producto en dos áreas principales: Analíticas y Procesos. 

En el caso de Melissa Perri, el libro empieza contando con una Product Manager que intenta tomar decisiones en base a datos, pero los datos llegan semanas después de que la Product Manager los pie.

¿No te suena esto como el Dogma #3 sobre los datos?

Como yo lo veo es que este nuevo dogma del rol de Product Operations viene a solucionar algunos de los problemas que se se suponía que los dogmas que he explicado anteriormente ya habían solucionado.

No digo que el nuevo dogma del Product Operations no ayude, pero por favor, con pinzas y adaptándolo a la cultura y formas de trabajo de la empresa, y únicamente si antes has solucionado el problema más urgente que hayas detectado en tu producto y organización. 

Nuevo Dogma #2: AI Product Management

El segundo dogma que se viene es el de la inteligencia artificial. 

Hablando con algunos líderes de producto que están trabajando en productos de inteligencia artificial, lo que llama la atención es que a veces se pierde la perspectiva lo siguiente:

Las funcionalidades con inteligencia artificial tienen que mover las métricas de toda la vida. 

Esto es, que si metes inteligencia artificial en tu producto es para mejorar una métrica, y el coste de ese esfuerzo tiene retorno de inversión, adelante, añade inteligencia artificial.

Pero habrá veces que añadir inteligencia artificial no sea rentable, ya que los modelos de inteligencia artificial dan resultados con mucha cantidad de datos, por lo que si estás arrancando una startup, quizás tengas que poner foco en validar tu modelo de negocio y dejar fuera la inteligencia artificial, al menos en un primer momento. 

Conclusiones 

Creo que es importante tener los consejos de los expertos de producto en la mente, pero ir adaptando y en ocasiones incluso ir en contra de lo que los expertos nos cuentan en libros y charlas.

Y es que a veces pasa, como en el caso de Amazon, que los mismos que crearon los dogmas que todo el mundo predica son los mismos que, al ponerlo en práctica se dan cuenta que no funcionan, y acaban por descartarlos.

Si dejas los dogmas de producto de lado, podrás ir aprendiendo sobre tu producto, tu empresa y tu industria, cambiando lo que no funciona, y celebrando cuando uno de los semáforos que estaba en rojo de repente cambie su color a verde.