¿Debería haber héroes en la gestión de productos?

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts utilizando un programa de software. Por favor, perdona cualquier error tipográfico, ya que el bot no es 100% preciso todo el tiempo.

Hannah Clark: Antes de sumergirnos, solo quiero aclarar exactamente a qué me refiero con héroes en la gestión de productos. No estoy hablando de líderes de pensamiento como Marty Cagan o Lenny Rachitski, hablo de TI. Hablo de la persona en la que tu equipo de producto confía para salvar el día cuando algo sale mal. Hablo del héroe que se pone muchos sombreros, pero nunca una capa. Hablo de la razón por la que no puedes trabajar menos de 50 horas a la semana y aun así sientes que no avanzas respecto a la semana anterior.

Y si eso te suena familiar, buenas noticias: el invitado de hoy es Clement Kao, fundador de Product Teacher. Habiendo formado a gestores de productos en todos los entornos, desde startups en etapas tempranas hasta empresas Fortune 500, ha visto muchas dinámicas de equipos de producto, incluyendo muchas que necesitaban un rescate serio.

Vamos a hablar sobre por qué ser el héroe de un equipo de producto es un peligro en sí mismo. Y si eso te resuena, quédate hasta el final para descubrir cómo obtener la fuerza sobrehumana para finalmente cambiar las cosas. Empecemos.

Bienvenidos nuevamente al Podcast del Gestor de Productos. Hoy estoy sentada con Clement Kao. Él es el fundador de Product Teacher.

Clement, muchas gracias por acompañarnos hoy.

Clement Kao: Sí. Muchas gracias por invitarme.

Hannah Clark: Vamos a comenzar como siempre. Si pudieras contarnos un poco sobre tu trayectoria y qué te llevó a fundar Product Teacher.

Clement Kao: Sí, fantástica pregunta. Originalmente, de hecho, no empecé en la gestión de productos justo al graduarme de la universidad.

De hecho, empecé como consultor de gestión. Luego, como consultor de gestión, accidentalmente me convertí en investigador UX. Después de eso, accidentalmente me convertí en analista de datos. Y de ahí, accidentalmente me convertí en gestor de productos. Así que tengo una trayectoria bastante poco convencional. Así que, sí, mientras seguía avanzando en mi carrera como gestor de productos, comenzando como gestor de productos asociado en el inicio de la escalera, luego ascendiendo a gestor de productos, PM senior, gestor de producto de grupo, gestor principal de producto.

Una de las cosas que noté fue que había muchas otras personas que luchaban de la misma manera que yo lo hice. Básicamente, sin tener necesariamente los recursos adecuados a la mano. ¿Cómo abordas este problema en particular? ¿Cómo superas determinado error? ¿Qué significan todos estos conceptos y por qué son importantes?

Y entonces, empecé a preguntarme, a medida que iba alcanzando puestos más senior como contribuidor individual en PM, cómo podría tener el mayor impacto posible. Y me di cuenta de que, hey, generar ese mayor impacto no era necesariamente seguir gestionando productos dentro de una empresa. Sino que, en realidad, ayudando a cientos o incluso miles de otros gestores de producto a tener éxito cuando empiezan por primera vez, ¿verdad?

Porque esa puede ser una transición muy confusa, y luego ayudándoles a ascender en el escalafón. Por eso decidí fundar Product Teacher. Product Teacher ha ayudado a más de 7.000 gestores de producto a tener éxito en el trabajo, ya sea para ingresar por primera vez al área de producto, obtener un ascenso o, como jefes de producto, establecer una estrategia de producto, asegurando procesos claros para todos los compañeros de equipo, etcétera.

Así que ha sido un camino increíblemente gratificante.

Hannah Clark: Genial. Y suena como la parte más intencional de tu trayectoria profesional y no...

Clement Kao: Sí. Fue lo único que no hice por accidente. Sí, sí.

Hannah Clark: Hoy vamos a explorar la idea del heroísmo en la gestión de productos, en la que pareces estar un poco en contra. Solo para dejarlo claro, ¿qué significa eso en este contexto y cómo lo ves manifestarse en las organizaciones con las que has trabajado?

Clement Kao: Sí, fantástica pregunta. Algo que quiero aclarar: no estoy diciendo que el heroísmo sea algo totalmente negativo, ¿vale? Una de las esencias del gestor de productos es que la responsabilidad final recae sobre ti.

Es tu responsabilidad asegurarte de que el producto tenga éxito y, ya sabes, estar dispuesto a ensuciarte las manos con lo que sea necesario. Ya sea que no tengamos un personal de QA y de repente necesitemos garantizar que todo esté bien probado antes de entrar en producción. O que nuestro diseñador esté enfermo y realmente necesitemos avanzar para habilitar a los ingenieros.

O que los clientes tengan dificultades para entender cierta parte del producto y tú tengas que asumir ese rol de operaciones de producto para implementar la solución y asegurarte de que las personas tengan éxito. Cualquiera que sea el caso, el gestor de producto necesita poder intervenir. Pero el problema principal que veo muchísimas veces con el tema del heroísmo en la gestión de productos es cuando se trata de algo que se espera que hagas siempre, en vez de ser algo que haces solo cuando es realmente, realmente, ¿cómo decirlo?

Cuando surge una excepción, ¿verdad? Así que, para aclarar, un gestor de productos sí debe ser capaz de intervenir y lograr que las cosas sucedan cuando sea necesario, pero no debería ser la persona que hace todo, todo el tiempo, ¿vale? Muchas veces, cuando la gente piensa: "Oh, este gestor de producto es todo un héroe, ¿verdad?"

Lo que realmente está ocurriendo es que asume muchas de las funciones laborales que corresponden a otros colegas para que el producto funcione. Y eso provoca que el resto de la organización se atrofie. Hay personas que no cumplen lo necesario desde la perspectiva del marketing de producto, de analytics, del éxito del cliente, de ventas, etcétera.

Todas esas áreas empiezan a debilitarse y a ser menos repetibles si dependemos de una sola persona para hacer todo. Y realmente he visto esto a mi alrededor. Cuando ese gestor de producto se enferma, se va de vacaciones o deja la organización, entonces todos se encuentran en una situación muy complicada, ¿verdad?

Así que quiero dejar claro que, por supuesto, los PM deben estar siempre dispuestos a intervenir cuando se necesite. Pero si la necesidad surge a diario o semanalmente, probablemente haya algo mucho más profundo que necesita ser atendido.

Hannah Clark: Sí, y creo que podemos imaginar algunas de las consecuencias lógicas de que un PM esté en esa posición todo el tiempo. Pero, ¿por qué crees que hay tantos gestores de producto en esa situación?

Clement Kao: Sí, fantástica pregunta. Creo que muchas veces los gestores de producto siguen en esa situación porque la forma en la que el trabajo ha cambiado con el tiempo es que todos funcionan de manera transversal, manejando varias cosas al mismo tiempo.

En el pasado, podrías decir: "Oh, tenemos un UX designer solo enfocado en una iniciativa". Ahora esa persona puede estar respaldando cinco productos. Quizá tengas un analista de negocio que solo debería enfocarse en una iniciativa, y ahora apoya a siete equipos diferentes, ¿verdad? Y como sucede todo este cruce de matrices, ya no es tan claro quién debe asumir cada responsabilidad. Así que, cuando algo falla, no es claro quién debe intervenir. Y por defecto, lo hace el gestor de producto.

Si hubiera mayor claridad sobre quién hace qué en cada caso, el PM no tendría que intervenir. Pero con el aumento de startups tecnológicas y equipos más pequeños y autónomos, a veces las directrices sobre quién debe hacer qué no están claras.

Y así, cada vez que pensamos: "No sabemos quién debe hacerlo", el gestor de producto termina haciéndolo. Y si lo hace una vez y lo hace bien, se convierte en un ciclo de refuerzo: "Oh, el gestor de producto lo hizo antes y lo hizo excelente. Mejor que yo mismo. ¿Por qué no se lo encargamos de nuevo?" He visto PMs asumiendo todo el tiempo roles como analytics, investigación de mercado, conversaciones con clientes o incluso cerrar ventas, simplemente porque lo hicieron mejor y ya hay otras prioridades.

Así que por eso veo cada vez más este tipo de situación en la última década.

Hannah Clark: ¿Dirías que hay señales tempranas de que una organización no ha hecho el trabajo de proteger a sus PMs de terminar en ese puesto de héroe, o simplemente no se han preparado desde el punto de vista de procesos?

Clement Kao: Sí, fantástica pregunta. Una forma en que lo pienso es como un "cuando lo ves". Si solo intervienes una vez, no pasa nada, es lo esperado. Pero si te das cuenta de que intervienes cada vez más seguido (mensual, en cada lanzamiento, ante cada bug...), hay un patrón. Si ocurre dos veces, conviene tener una conversación más profunda.

Si estás en una organización que valora las retrospectivas o no las tienes, deberías introducirlas para analizar por qué ocurrió el problema.

Si tras la primera vez ya lo abordan, idealmente no debería volver a ocurrir. Si sucede otra vez, esa retro debería analizar el patrón. Así se detecta la sobresaturación de los PMs con tareas fuera de alcance de manera habitual, lo cual no es lo que queremos.

Hannah Clark: Así que al organizar estas retrospectivas, parece una solución poco atractiva para un problema así.

Clement Kao: Es poco carismático. Sí.

Hannah Clark: Por desgracia. ¿Qué proceso debe seguir un PM para hacer una retro adecuada que logre que todos se involucren en los cambios necesarios para remediar una situación como esta?

Clement Kao: Lo importante en una retro es asegurar que sea sin buscar culpables, hablando del sistema y no de las personas. ¿A qué me refiero? No queremos discutir culpando a individuos. Pongamos un ejemplo: un cliente enterprise muy frustrado con la experiencia. Un PM sabe programar y, por cualquier razón, los ingenieros no pueden hacer un cambio de copy a tiempo. Así que el PM lo hace, sube el código y lo despliega.

Debemos analizar en retrospectiva: no se trata de decir "este ingeniero estaba ocupado y por eso", eso es señalar. Más bien: ¿Por qué, cuando el cliente planteó ese problema hace 6 meses, no lo atendimos antes? ¿Por qué esperamos hasta que se iba a cancelar el contrato para intervenir?

Hay que analizar desde el punto de vista del sistema. Si esto pasa de nuevo, ¿qué podríamos mejorar en el proceso y como sistema para solucionarlo mejor?

Hace poco leía sobre control aéreo. Si bien el controlador está allí cuando ocurre algo, la culpa no es 100% suya: hay todo un sistema detrás que puede fallar. Y no queremos que todo dependa de un solo punto de falla.

Eso buscamos en la retro: auditar el sistema, ver qué falló, cómo mejorarlo para todos la próxima vez. No solo en el PM para que cada vez tenga que intervenir, sino que existan apoyos y procesos que permitan que no todo dependa de esa persona.

Si ante cualquier charla con clientes tienes que tener al PM, deberíamos redefinir ese proceso.

Hannah Clark: Tiene sentido. Hay que reconstruir a partir del problema para dar con la solución. En tu experiencia con equipos de producto, ¿has visto organizaciones corregir esto exitosamente? ¿Puedes contarnos, sin nombres, cómo fue?

Clement Kao: Sí. Primero hablaré de mi propio caso. En un momento, terminé haciendo todas las tareas de operaciones de producto cuando no me correspondía. En el lanzamiento de un nuevo vertical de producto B2B SaaS, como ya había hecho la investigación de usuario, entendía las necesidades del cliente y me encargaba de las notas de lanzamiento y grabaciones. Eso funcionaba cuando solo había tres clientes, pero cuando llegamos al número 70, fallé al no levantar la mano en el número 10 o 15 y decir "esto no es mi trabajo".

Pensaba: "Como PM, debo garantizar el éxito del producto a toda costa". No lo planteé como que estaba quitando oportunidades a marketing, customer success, etc. para tener visión total del cliente.

Me auto-perpetué en estas tareas, creyendo que "una vez más no hace daño", y acabé perjudicando a mis compañeros, impidiendo que se responsabilizasen de principio a fin. Así, nuevas incorporaciones me buscaban una a una para la configuración, cuando alguien debería haber documentado cómo hacerlo, con vídeos, ejemplos, preguntas de onboarding, etc.

Tuve la suerte de tener un gerente increíble. Él me dijo: "Clement, veo que estás saturado y haciendo tareas que no son tuyas". Respondí que sí, pero sentía que mi deber era asegurar el producto. Él contestó: "Está bien, pero así no creamos un sistema robusto para el largo plazo". Podía con 10 clientes, pero ¿cuando dobremos el año próximo? ¿100 o 140 clientes?

Así que reunimos a todos los involucrados para discutir a quién pertenecía cada responsabilidad. Lo enmarcamos no como una carga, sino como una oportunidad para que otros asuman y adquieran nuevas habilidades. Que puedan aportar un mayor valor al cliente.

En este caso, funcionó por 1) el apoyo de la dirección de producto en definir lo que no debíamos hacer y 2) en el enfoque de transferir responsabilidades como una oportunidad, no una carga. Después, comprobamos regularmente cómo iba la transición, transferimos conocimientos y nos aseguramos de que no fuese simplemente "lanzar la pelota al otro campo" sin preparación. Así, los nuevos responsables pueden incluso mejorar los procesos, no solo repetir los míos.

Así que he vivido ese error en carne propia, pero también tengo ejemplos de otras organizaciones...

Hannah Clark: Sí. Si tienes otro ejemplo, quizá más reciente, que ilustre el asunto. Me gusta cómo enmarcas esto como poder devolver agencia al equipo y compartir la carga, porque yo también lo he visto en empresas en las que alguien asume injustamente una responsabilidad que no le corresponde, lo que frena su crecimiento y el de los demás. ¿Tienes algún ejemplo que ilustre otro aspecto de este concepto?

Clement Kao: Sí, tengo uno muy reciente. Trabajo ahora con una organización grande donde el equipo de producto es relativamente nuevo. Todos venían de ser solution architects: antes, la empresa hacía soluciones personalizadas para cada cliente, no productos escalables. Decidieron crear un equipo de producto, ya que los casos de uso eran similares y convenía crear una tecnología robusta y escalable.

Así que algunos solution architects pasaron al área de producto para ver cómo reutilizar todo hacia problemas tecnológicos escalables, no solo soluciones ad hoc.

Pero, por ese background, este equipo caía en el error de seguir haciendo tareas de solution architect para sus clientes internos, incluso diseñando los procesos y sistemas de integración para las necesidades de cada cliente.

Esto generó pisar los pies a los solution architects "puros", que pensaban: "Ahora este equipo, con acceso directo al CEO, debe haberme relevado en mi función, aunque no debería ser así". Como el equipo de producto quería asegurarse de que su plataforma se adoptara bien, también intervenían en todo el ecosistema, no solo el core del producto.

Pero en realidad, el architect es quien debe conectar los sistemas específicos del cliente. Así el PM puede centrarse en el core y los architects en las integraciones personalizadas. Pasar del 1:1 de un PM por cliente, que no escala, a 1 PM core y múltiples architects para integrar distintos clientes.

Esto requirió varias conversaciones con todo el equipo para aclarar roles. Por suerte, el equipo fue receptivo y lo ajustamos antes de que el malentendido se consolidara durante años. Así evitamos que el PM termine siendo el "héroe" de cada despliegue, recayendo en él todo el trabajo.

Lo interesante es que este equipo provenía completamente de solution architects, así que era natural ese sesgo. Fue cuestión de mentalidad y madurez para escalar a largo plazo. Así, cada quien asume lo suyo y no partes fragmentadas.

Hannah Clark: Quisiera profundizar en las mentalidades y la madurez organizacional. He observado (y es común) que, a medida que una organización madura y los procesos se complican, el desbordamiento y la saturación pueden parecer el único camino, aunque no sea sostenible. Es difícil salir de esa situación de sobrecarga y atrofia organizacional.

Veo aquí varias fases: motivación para cambiar y capacidad de actuar/abogar por el cambio. ¿Qué luz al final del túnel puede esperar alguien que ya está muy saturado si hace el esfuerzo de liberarse de esas ataduras?

¿Cómo abogar por uno mismo en una organización en esa etapa?

Clement Kao: Muy buena pregunta. Yo iría de abajo arriba. Lo primero es reconocer que estás desbordado más allá de lo que aceptaste inicialmente. A menudo este reconocimiento no sucede porque estás tan ocupado que ni tiempo tienes para reflexionar si tu trabajo realmente es gestionar producto.

Algo útil es tomar 10 minutos al inicio o final de la semana para reflexionar: ¿lo que hago realmente es producto? ¿Estoy moviendo los indicadores clave? ¿Hay tareas que absorbo simplemente porque "toca" y que en realidad no son el valor más alto que puedo aportar?

El primer paso es la autoconciencia, porque si no reconoces la raíz, es imposible abogar por ti mismo.

La segunda parte es lograr el apoyo de tu gerente. Muchas veces, los jefes no saben que estás cubriendo todo eso, no por desinterés, sino porque tienen sus propios objetivos y equipos. Cuando ven que pasas 10 horas semanales en tareas ajenas, suelen sorprenderse y agradecen que lo digas, pues afecta sus propios resultados también.

Llega no sólo con el tiempo empleado, sino con alguna hipótesis sobre por qué terminas haciendo esas tareas, para facilitar la conversación. Si ambos están alineados en esto, se puede avanzar a redistribuir.

Después, analiza con quién tiene más sentido que recaigan ciertas funciones: ¿tienes un diseñador? ¿Un equipo de analytics? Quizá podrían automatizar tareas manuales y permitir escalar todo el proceso, en vez de que tú seas el "héroe" cada vez.

Propón qué tareas serían más escalables bajo otros equipos, por qué, y colaborad para ese rebalanceo. Haz un traspaso gradual, asegurando el contexto adecuado para que la otra parte tenga éxito. Cuando todo esté asentado, tendrás mucho más tiempo —el que siempre debiste tener— para lo esencial: comprensión profunda de clientes, creatividad con diseño e ingeniería, pensar en la estrategia de negocio, etcétera.

Tendrás una mente más despejada para centrarte en lo nuclear del producto.

Sé que es duro; a mí me costó mucho. Pero los frutos valen la pena: mayor impacto y conexión con clientes, gracias a disponer del tiempo real para ello.

Otro consejo adicional: muchos PMs quieren tanto que los demás tengan éxito que se dejan a sí mismos para lo último. Siempre llega otra tarea "urgente" y nunca se dedican 10 minutos a pensar cómo delegar o repartirse mejor el trabajo. Lo que me ayudó fue dividirme en dos: el Clement executor, y el Clement líder de producto (incluso con otro nombre, el mío es Richard). Richard espera de mí un plan para trabajar de manera más sostenible.

Así, hacía una cita conmigo mismo (con Richard) para revisar el plan de escalabilidad, y si no había avances, Richard se disgustaba. Suena loco, pero me ayudó a distinguir el rol estratégico y a dedicar tiempo a mi propio desarrollo. Recordemos que nosotros mismos somos stakeholders clave, y no podemos ignorar al "gestor de producto" mientras ejecutamos.

Esto sirve no solo para repartir tareas, sino para cualquier crecimiento profesional de producto.

Hannah Clark: Me encantan las tácticas poco convencionales y en especial la capacidad de externalizar tu valor y lo que aportas al equipo. Realmente, lo más heroico que puedes hacer en tu organización es empoderar al resto y así, indirectamente, a ti mismo.

Clement, muchísimas gracias por acompañarnos. Ha sido fantástico. Siempre aprecio tus aportes; tienes mucho que ofrecer en este campo. ¿Dónde puede la gente encontrarte online?

Clement Kao: Buena pregunta. Siempre pueden encontrarme en LinkedIn, probablemente sea el único Clement Kao. También en productteacher.com, todo junto y sin guiones. Allí es donde suelo estar y ayudar a la comunidad de producto.

Hannah Clark: Genial. Nos vemos allí.

Clement Kao: Genial. Gracias por invitarme.

Hannah Clark: Gracias por escucharnos. Para más ideas, guías prácticas y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más charlas como esta suscribiéndote a The CPO Club, donde sea que escuches tus pódcasts.