CharlaProduct Strategy y negocio21 de noviembre de 20233 min de lectura

Lo que conté en The Hero Camp sobre el día a día real de un PM

Los manuales dicen que un PM tiene que ser un gran comunicador y vivir en reuniones. Yo conté, desde lo que he vivido, que ni una cosa ni la otra.

The Hero Camp me invitó a contar mi salto de diseñadora y frontend a Product Manager, cuando llevaba algo más de dos años en el rol en Genially. Esto es lo que defendí:

  1. El PM es un rol casi de alquimista. Alguien capaz de alinear la necesidad del usuario, la estrategia de negocio y la evolución del producto, y de convertir ese equilibrio en una entrega de valor. Los perfiles de diseño defienden al usuario y su experiencia con el producto; negocio busca crecimiento y rentabilidad; y el equipo de tecnología ansía robustez y escalabilidad. Mi «batalla» como PM es que las tres piezas estén equilibradas, sin ir «como un peregrino» contando discursos a unos y a otros sino desde el entendimiento y la optimización de la solución.
Mi forma de verlo: la batalla del PM es equilibrar negocio, diseño y tecnología
  1. Comunicar no es hablar bien. «No somos locutores de radio.» Nuestro reto es decidir con cuidado qué decir, a quién, cuándo, con qué fin y por qué canal. A veces basta un mensaje por Slack un martes a primera hora; otras, la estrategia pide varias fases y artefactos comunicativos. Uno de mis errores más repetidos ha sido apresurarme a comunicar sin valorar antes si esa información le hacía falta a quien la recibe. Trasladar información solo para quitártela de encima es muy fácil: te descarga a ti, pero no siempre ayuda a los demás. Ahora intento siempre recordar lo que divulga la psicóloga Olga Castanyer sobre comunicación asertiva: expresarse con claridad, pero teniendo en cuenta la perspectiva de quien escucha (más aquí). Y por «perspectiva» entiendo no solo su visión, sino también su contexto, su momento y su necesidad.

  2. «Que no nos secuestre la metodología.» Los frameworks se aplican de forma flexible y ordenada, no todos a la vez ni todos por obligación. Ante la tentación de matar moscas a cañonazos, o ante la parálisis por análisis, a mí me funciona dar tres pasos atrás, tomar distancia con objetividad y sopesar esfuerzo frente a riesgo.

Lo que más me costó al empezar como PM
  1. El mito de las reuniones. El PM no vive reunido: primero, trabajo individual y asíncrono; y reunión solo con trabajo previo y accionables claros. El teletrabajo nos ha llenado la agenda de videollamadas, pero gestionarla bien es primordial y responsabilidad tuya: reclama y proporciona el espacio necesario para trabajar.

  2. La frutería. Es el miedo más común que veo en perfiles con poco background técnico. Pero no hace falta ser hacker, y menos ahora, en tiempos de IA. Aun así, saber qué es frontend, backend, una API, un hook o un servidor te da ventaja a la hora de identificar oportunidades, igual que en una frutería saber que los tomates son de verano y las calabazas de otoño te ayuda a planificar una buena estrategia de compra y de venta. El PM traduce, y difícilmente se traduce lo que no se entiende. Y ojo, porque la IA no elimina esa necesidad, la refuerza: programar cuesta cada vez menos, pero decidir con agilidad exige más criterio técnico. Una señal de ello es el nacimiento de roles nuevos en producto, como el product builder, el product engineer o el product maker, que se mueven más cerca de ese terreno.

Y una confesión que también hice en la charla: la comunicación verbal es donde más sentía que tenía que mejorar. Casi tres años después, probablemente siga siendo el reto que más me motiva mejorar.