Hoy voy a tratar un tema distinto, del que no se suele hablar pero que creo que es útil y necesario para todos los product managers, básicamente porque nos ayuda a quitarnos cierto peso de los hombros, sobre todo si eres como yo y tienes un síndrome del impostor del tamaño de varios campos de fútbol.

Empezaré por el principio.

En la actualidad tenemos a nuestra disposición infinitos libros y artículos sobre frameworks de priorización, técnicas de discovery, ejercicios de research, casos de éxito de optimización de funnel. Existen podcasts sobre el proceso de diseño en Apple, sobre comunicación entre equipos y team topologies, nos sabemos todos los canvas necesarios para evaluar nuestro modelo de negocio, metodologías de roadmapping, integramos un dual track de investigación con sprints para poder entregar valor cuanto antes.

Y con esta caja de herramientas tan grande, podría parecer que el trabajo de Product Manager es fácil – más que fácil, infalible. Para cada problema o reto hay un framework, modelo mental o herramienta que podemos utilizar. Tan sencillo como utilizar cada técnica en su momento para tener impacto y proporcionar business value.

Pero esto no es así, ni mucho menos.

Así que aquí va el asunto: nada de esto te asegura el éxito. Todo lo que he descrito son herramientas de reducción de riesgo, pero el riesgo siempre existe, nunca se puede bajar a cero (nunca estaré lo suficientemente agradecido a mi mentora Meghan por enseñarme esto).

Lo expreso de nuevo, esta vez con otras palabras: Puedes hacer tu trabajo perfecto y que aún así no tengas éxito o impacto. Siempre existirán factores externos (o incluso internos al squad o equipo) fuera de tu control.

Por enumerar algunos:

• Competidores mucho más fuertes, con más inversión, equipo o recursos. Por muy bien que hayas priorizado e implementado tus últimas features, si tu competidor tiene un producto mucho más refinado que el tuyo y ataca a tu mismo target… lo tienes complicado. Tan sencillo como acordarse de aquellas veces que Google o Apple se han cargado a startups simplemente copiando su producto.
• Problemas de comunicación con otros departamentos u objetivos no alineados – porque no sería la primera vez que existen dos departamentos o equipos con KPIs u objetivos enfrentados.
• Dificultades organizativas en la empresa externas a tu influencia.
• Cambios en las circunstancias geopolíticas, económicas o incluso sanitarias. Guerra entre Rusia y Ucrania, pandemia global…
• Cambios legislativos. Por poner algunos ejemplos, la entrada de normativas sobre VTC, nuevas leyes sobre Riders, actualizaciones en las normativas de alquiler de pisos vacacionales…
• Limitación de staffing de ciertos roles críticos en tu squad, baja performance o falta de seniority. Este punto te afectará mucho más si eres t-shaped como yo. Por ejemplo, más de una vez me he sorprendido a mí mismo pensando que “podía haber presentado esta interfaz de otra forma a los stakeholders para obtener buy-in”, para luego darme cuenta de que realmente esa no es mi responsabilidad.
• Alto impacto del Highest Paid Person. Amigo mío, puedes prepararte un workshop perfecto para priorizar el siguiente Q, que si el Hippo interviene y cambia las prioridades, la estrategia o dicta en campos como interfaz o implementación técnica, estás jodido. Por cierto, no os perdáis el fantástico artículo The Highest Paid Person’s Opinion de Jeff Gothelef.
• Budget limitado para adquirir ciertas herramientas, o dificultades y burocrácia innecesaria desde el departamento responsable.
• Dependencias externas o de otros equipos. Mención especial a cuando varios squads comparten roles clave (como Product Designer, QA, devops o infra, copywriter, etc), o tenéis bloqueos externos necesarios para llevar a cabo vuestro proyecto
• Pobre definición de estrategia, métricas o KPIs top-down, que pueden hacer que el VP o C-level te obligue a apuntar en la dirección no adecuada.
• Falta de cultura de producto en la empresa – y esta es especialmente compleja de combatir, porque por mucho Escaping the build trap que apliques, es muy difícil cambiar la cultura de una empresa, y terriblemente frustrante.
• Que te asignen en un proyecto con mucho sunk cost por parte de la empresa – si a eso le sumas que la empresa tenga poca cultura de cerrar proyectos o features, todo se complica.
• Falta de alineamiento o expectativas de un Product Manager. Si le preguntas a 5 personas de la industria cuáles son las tareas y responsabilidades de un Product Manager, probablemente obtengas 5 definiciones muy diferentes.

En fin, esto son simplemente las que se me vienen a la cabeza, pero seguro que podrías pensar en algún caso más.

---

Este post no va de evitar responsabilidades, sino de echarle una mano a esos Product Managers como yo en los que se de algunas de las siguientes circunstancias:

• Tener un background muy diverso (en mi caso he trabajado profesionalmente tanto de Ingeniero como de Product designer)
• Ser una persona con locus de control interno y/o síndrome del impostor.

La idea de escribir este artículo me vino después de leer La responsabilidad de ser Product Manager de la newsletter Estrategia de Producto de Simón Muñoz (una newsletter súper recomentable, por cierto). Suelo estar muy alineado con Simón, pero en este caso hay detalles que no comparto. Estoy totalmente de acuerdo con la parte de que tenemos la responsabilidad de dar valor, también creo que somos líderes sin ninguna autoridad formal, y creo que estas dos ideas (ciertas pero enfrentadas) nos genera un doblepensar frustrante y difícil de gestionar.

Y lo más curioso de esto es que Simón ya habla de ello en Resiliencia: Adáptate o muere. En este artículo se comparte un post de Reddit que me parece un food for thought brutal, y que paso a reproducir a continuación:

As a product manager, I stopped doing product management and became happier as a result.

I became enamoured with product management after reading Inspired by Marty Cagan and drinking all the koolaid like Continuous Discovery Habits etc.

I struggled for years trying to coach my teams, my stakeholders, my leadership on product management practices but mostly it fell into deaf ears. The truth is, people just want to deliver features.

So I stopped doing product management. Executive A thinks we should build X? Yes sir coming right up. Stakeholder B thinks we should do Y? Absolutely, I'll put it in the backlog. I've become a glorified highly paid order taker now, but I just don't care anymore. Product discovery? Hah. Why do it if no one understands the need for it? I'll just deliver the feature everyone thinks we should do.

The result? I'm much happier, less stressed and I can get my 200k pay check by coasting and playing the corporate game. Great if you can do real product management but 97% of all companies don't care about it nor understand it.

Anyone else with a similar epiphany or change like this?

Post como este te dejan tocado. Y te abren los ojos para aceptar una realidad que es muy diferente a lo que vemos en la gran mayoría de libros sobre producto.

Somos una pieza del engranaje de todo el squad, una pieza crítica (el linchpin que dicen los ingleses) pero no somos la única responsable de que todo funcione.

Recuerdo un Managing Director que me inculcó el mantra de Make it happen. Un mantra genial, que personalmente siempre me ha ayudado, pero que tiene un doble filo que debemos conocer.

Porque aquí hay que saber cuándo luchar contra el mar y cuándo toca coger la ola.

Sunset waves by Ignacio Palomo Duarte