- El debate sobre cuántos PM debería tener un equipo de producto se intensificó tras la reorganización del área de gestión de producto de Airbnb y los casos de startups que crecen sin PM
- A medida que aumenta la cantidad de PM, puede surgir una estructura en la que se dedica más tiempo a gestión de proyectos y actualizaciones del roadmap que a los resultados de negocio del producto
- En equipos con diseñadores e ingenieros experimentados, el trabajo de PM no necesariamente debe ser de tiempo completo, y el modelo de 1 PM por equipo también debería revisarse según el contexto
- La primera contratación de un PM suele considerarse cuando al fundador le resulta difícil participar en todas las decisiones importantes de producto; por lo general, alrededor de 50 a 100 personas y 3 a 5 equipos de producto
- Aumentar el número de PM no convierte por sí solo a una organización en una centrada en producto; de hecho, puede debilitar el sentido de responsabilidad sobre el producto que deberían tener diseñadores e ingenieros
Reducir PM y ampliar la responsabilidad sobre el producto
- La discusión sobre cuántos PM se necesitan se volvió más activa después de la reorganización del área de gestión de producto de Airbnb y de artículos sobre startups que crecen incluso sin PM
- En muchas empresas, los PM suelen llenar su día con tareas como gestión de proyectos y actualizaciones del roadmap, en lugar de optimizar el producto para el negocio
- En general, debería haber menos PM que equipos de producto, y la estructura de asignar 1 PM a cada equipo debe revisarse según el producto y la situación del equipo
- Si hay mucho trabajo de producto y el equipo es junior, puede ser necesario un PM dedicado para un equipo
- En equipos con ingenieros y diseñadores con mucha experiencia, el rol de PM puede no necesitar ser de tiempo completo, o incluso no debería serlo
- El momento adecuado para contratar al primer PM en una startup es cuando al fundador le resulta difícil participar en todas las decisiones importantes de producto
- Por lo general, el punto de referencia es cuando la organización tiene 50 a 100 personas y 3 a 5 equipos de producto
- La estrategia general de producto ya debe estar clara, y el PM debe participar en direcciones y decisiones de menor nivel a partir de esa estrategia
- Para el primer PM, es más adecuado un PM senior que un PM junior o un CPO
- El candidato puede llegar a asumir el rol de CPO a medida que la organización crece, pero el fundador debe seguir actuando, en la práctica, como responsable de producto
Prácticas para crear un equipo centrado en producto
- La responsabilidad sobre el producto no debe concentrarse en un solo PM; diseño e ingeniería también deben entender directamente a los usuarios y el contexto del producto
- Diseñadores e ingenieros deben participar activamente en la formación del producto y liderar las conversaciones detalladas sobre producto
- El PM no debe ser quien se encargue por sí solo de UX, wireframes, seguimiento del avance, conducción de standups ni redacción de PRD/especificaciones
- El foco del PM está en expresar la visión del producto, elegir los problemas correctos, mantener la dirección del producto y alinearla con las necesidades del negocio
- La “Guide to product development” de Michael Seibel se conecta con el caso de implementación de este enfoque en Social Cam
- El equipo debe compartir activamente el contexto y los fundamentos de sus decisiones
- Diseño e ingeniería también deben poder acceder al feedback de usuarios
- La resolución de problemas no debe estar centrada en el PM, sino ser una colaboración entre producto, diseño e ingeniería
- Las prácticas para crear un equipo orientado a producto pueden resumirse en cuatro puntos
- Empezar juntos: antes de escribir tickets o especificaciones, antes de decidir una solución, diseño, ingeniería y producto/fundadores conversan en conjunto para alinear la forma de trabajo y el plan
- Exponer a todos a los usuarios: hacer que participen directamente en investigación de usuarios y pruebas de usabilidad, o que vean a los usuarios usando el producto mediante video en streaming o herramientas como Lookback
- Tener cuidado con la forma de gestionar al equipo: si el desempeño se mide por la cantidad de tickets cerrados o story points, el equipo se moverá en función de procesar tickets, no de crear un buen producto
- No usar herramientas de PM: si el feedback de usuarios, insights, datos, especificaciones y roadmaps quedan encerrados en herramientas separadas de PM, a todo el equipo le resultará difícil acceder al contexto del producto
- El desarrollo de producto es inherentemente difícil de predecir, y es más importante lanzar lo correcto, aquello que impacta en el negocio, que el lanzamiento en sí
- En grandes empresas centradas en producto, los PM son muy importantes, pero la cantidad de PM necesaria puede sobreestimarse fácilmente, y aumentar el número de PM no implica necesariamente una mayor concentración en el producto
1 comentarios
Opiniones de Hacker News
Como gerente de ingeniería o líder de una organización funcional, trabajé bastante tiempo con gerentes de producto, y en una empresa tecnológica mediana también hice de PM interino para productos internos.
Creo que la gestión de producto está entre las áreas más importantes de lo que hace una empresa. Pero el trabajo es realmente difícil, y cuanto menos capaz es un PM, más fácil es que se aleje de eso y termine en microgestión o política interna bajo el pretexto de “liderar” al equipo de ingeniería.
En organizaciones donde ingeniería y producto están divididos en cadenas de mando separadas, es difícil manejar este problema, y aunque lo escales hacia arriba, el ancho de banda de ese lado naturalmente es muy limitado. Desde el punto de vista de un EM, estos PM suelen hacerles la vida difícil a los mejores ingenieros y, al final, con frecuencia provocan que se vayan.
Hoy creo que lo mejor es poner en cada equipo un PM con forma de mini-CEO y, si no tiene suficiente solvencia técnica, emparejarlo con un mini-CTO. Así hay mucho menos espacio para la política y mucho más para el trabajo en equipo.
Los equipos más exitosos en los que estuve no tenían un rol dedicado de producto, y todas las decisiones las tomaban los desarrolladores.
Ahora creo que lo mejor es quitar del camino de los desarrolladores incluso al personal no técnico o a la gente apenas técnica, para que los desarrolladores puedan construir en paz.
Lo que veo es gente defendiendo sus opciones y tratando de conseguir apoyo. Nunca he visto esa política de la que la gente se queja. Tal vez solo he tenido suerte.
¿Política significa alguien que está técnicamente equivocado pero argumenta de forma más convincente? ¿Qué es “política”? ¿O será que todavía no tengo un puesto lo suficientemente alto, aunque sea senior principal?
Este artículo y mucha gente que intenta analizar este tema están pasando por alto un elemento clave: los incentivos.
Muchos desarrolladores sienten más pasión por la tecnología en sí: programar, resolver problemas técnicos complejos y crear soluciones eficientes. Las recompensas formales, como ascensos, bonos y reconocimiento, también suelen estar vinculadas a logros técnicos.
Si un desarrollador dedica 40 horas a investigación de clientes, quizá no reciba el mismo reconocimiento o recompensa formal que por un logro técnico, como desarrollar una nueva solución de autenticación que beneficie a todo el equipo.
Cambiar esta dinámica no se logra solo recomendándoles a los desarrolladores que dediquen más tiempo a gestión de producto. Se necesita un cambio sistémico en lo que la organización valora y en cómo lo recompensa.
Si la estructura de incentivos pasa de estar centrada en la tecnología a estar centrada en el usuario, eso afecta mucho el rol de los mandos medios y altos. Un cambio así sacude la base de sus roles y responsabilidades, y puede llevar a una pérdida de control e influencia.
Por eso es muy probable que ese tipo de cambio encuentre una resistencia sutil pero fuerte por parte de los mandos medios y altos. Muchas veces tienen bastante poder político e intereses adquiridos dentro de la organización.
Todo oficio artesanal se aprende en el momento de contacto real. Un director de cine puede ver su película mil veces en la sala de edición, pero verla una sola vez por primera vez junto a una audiencia real le enseña más que esas mil horas.
Un carpintero puede sentirse satisfecho fabricando muebles toda la semana, pero el momento real llega cuando ese mueble queda instalado en la habitación del cliente. Con el software pasa lo mismo.
Para que un ingeniero de software se preocupe por los usuarios, tiene que recibir feedback directo sobre qué funciona bien y qué es pésimo, y si es posible verlo con sus propios ojos.
Un ingeniero de software decente siente cierto orgullo por hacer bien su trabajo. Si ese orgullo está ligado solo al código, al historial de commits y a otros conceptos abstractos, y no tiene ningún contacto con qué tan bien le sirve a usuarios reales, ¿cómo va a empezar siquiera a importarle?
Casi no tiene relación con el artículo, pero la tendencia actual de usar imágenes de IA como imagen principal de los posts de blog me vuelve loco.
Si al escribir no se te ocurrió una imagen principal clara, preferiría que no desperdiciaras mi ancho de banda descargando un sueño febril de una computadora.
Estoy a favor de las imágenes de IA porque son una herramienta muy valiosa. Pero si vas a usar una imagen de IA como la única imagen de la página, de verdad debería haber una buena razón, no ser simple relleno.
Especialmente si ni siquiera curaste bien la cantidad de dedos que tiene cada persona en la imagen generada.
La imagen tiene el objetivo de transmitir una sensación. Busca volver un poco más tangible el concepto abstracto del artículo.
Antes buscaba en internet una imagen que cumpliera ese propósito. Ahora puedo crearla directamente con DALL-E, y normalmente queda mucho mejor.
Esta imagen debería complementar el artículo. Así como el texto del artículo intenta transmitir información, sensación y conceptos, la imagen también debería hacer parte de eso.
Nadie quiere ver una imagen con gente de todos los principales grupos raciales parada en círculo, sonriéndose raro entre sí, con una vibra de valle inquietante.
Esta moda de ilustraciones corporativas extrañas y sin alma empezó antes de que la generación con IA se volviera explosivamente popular.
Tal vez sea por alguna creencia sobre la optimización para motores de búsqueda.
Al mismo tiempo, solo tiene que verse bien.
Aunque aquí hay algo bastante gracioso. Como la plantilla del blog exige un área de imagen, se rellena sin pensarlo con cualquier cosa. Si eso resulta demasiado difícil, se busca una foto de stock insípida; y si eso también es difícil, se genera deliberadamente una foto de stock insípida.
Siento que la basura de IA sin inspiración ni gusto pronto lo va a cubrir todo.
La mayoría de los problemas de los PM están en que no hacen trabajo de campo. Un buen PM debe cerrar continuamente la brecha entre ingeniería y los usuarios
Hay que repetir este ciclo de feedback
Pero la mayoría cree que puede trabajar solo en el mundo de los documentos: produce documentos de roadmap y trata de mantener alineados a los stakeholders con check-ins interminables y regaños. Al final, lo que está haciendo es trabajo de “project manager”
Mandaba siempre a un desarrollador senior o a un tech lead a recopilar requisitos, atender a usuarios furiosos por bugs, reuniones semanales de estado e incluso dar malas noticias sobre prioridades. Se saltaba la mayoría de las ceremonias ágiles diciendo que era una persona ocupada. Nunca escribió ni corrigió un ticket de JIRA, y decía que eso era algo que debía gestionar la organización técnica. Hizo lo mismo como PM con otros dos equipos técnicos
Los tech leads y desarrolladores senior supieron desde la primera semana que ese PM no era bueno, pero duró más que todos nosotros y recién se fue 4 años después por una reducción de personal
La gerencia atrapada en el culto a Agile se deja fascinar fácilmente por este tipo de personas, y puede desviar a una organización durante años. En teoría, el stakeholder de un PM es el usuario, pero en la práctica termina puliendo el ego de los altos ejecutivos que lo contrataron
Puede formarse un ciclo cerrado de autorrefuerzo entre altos ejecutivos, consultores ágiles y PMs
En ambos casos son productos poco competitivos y, por lo general, es probable que se queden así hasta que se descontinúen. Aun así, las empresas tienen PMs y POs, arman algo parecido a SCRUM y actúan como si estuvieran creando un producto revolucionario. Incluida la urgencia y la presión por resultados
En estos entornos, muchas veces los PMs y POs tienen poco interés en hacer buenos productos o productos usables, y se concentran en la política interna para subir en la escalera corporativa
Aunque construyan productos fragmentados que, en términos de funciones y mejoras, parecen una caminata aleatoria, empujan el proyecto en la dirección que los haga verse bien ante la gerencia o los clientes
No tengo edad suficiente para saber cómo se construía en los años 60, 70 y 80, pero imagino que no había SCRUM/PM/PO. La narrativa pesimista de que la productividad se desaceleró mucho frente a décadas pasadas y que hoy en general vivimos de lo que se creó antes encaja bastante bien con mi percepción
Últimamente estoy mentoreando a otros PMs. También hay roadmaps ampliamente compartidos, pero se crean muchísimos documentos y hojas de cálculo que nadie vuelve a mirar salvo yo. Me da la impresión de que se hacen para demostrar que se está trabajando, y trato de romper ese hábito
Defiendo con fuerza la gestión técnica de producto porque, si simplificamos el problema, creo que algunos PMs quedan atrapados en un nivel de abstracción demasiado alto. Como no pueden hablar todos los días con el equipo sobre detalles técnicos, terminan quedándose en una extraña zona gris entre project management y product management
Eso en sí está bien, pero si existe el síndrome HIPPO de querer tomar decisiones de producto, terminas usando la mayor parte del tiempo en cubrirte las espaldas y gestionar hacia arriba
Los PMs reciben muchos golpes, a veces merecidos, pero al final muchas veces tienen que hacer política interna para lograr que las cosas avancen
Un gran PM no solo crea una visión o un plan, también lidera la ejecución y la iteración. El plan es el 20% del total
El mejor product manager con el que trabajé era simplemente una persona extremadamente capaz: entendía la complejidad de implementación e incluso podría haberlo hecho él mismo si hacía falta, y al mismo tiempo entendía las necesidades del negocio
No era engineering manager, pero aportaba valor a la empresa
Por desgracia, la mayoría de los product managers solo son personas sentadas en ese puesto. Son guardianes de acceso que se atribuyen méritos o responsabilidades, y muchas veces tienen muy poco en juego personalmente
En general, creo que si existe una organización separada de product management, lo están haciendo mal
Los mejores y más exitosos productos en los que participé fueron todos aquellos en los que los implementadores reales tenían ownership del producto. Personas como ingenieros, diseñadores y equipos de customer success
Como ingeniero, me gustaba entrar en la rotación de soporte, porque cerraba la brecha de abstracción entre mi trabajo y las personas reales que lo usaban a cada segundo
En muy raras ocasiones trabajé con PMs que aportaban valor neto, y en todos esos casos eran personas que también podrían haber sido buenos ingenieros
La razón principal es que, si el PM o la persona del equipo que cumple ese rol reporta dentro de la misma estructura de gestión de ingeniería, todo termina inclinándose hacia las necesidades de ingeniería
Incluso el trabajo de funciones indispensables con alta probabilidad de impulsar el negocio termina relegado en la prioridad, porque la deuda técnica o el trabajo de infraestructura siempre, de alguna manera, está bloqueando a la gente. A veces esa puede ser realmente la decisión correcta, pero para tomar esas decisiones se necesita tensión entre dos organizaciones con el mismo peso. Cuando eso forma parte de ingeniería, no suele ocurrir
Por supuesto, la triste realidad de nuestra industria es que una organización de PM separada, por ser dueña de “lo que es bueno para el negocio”, termina teniendo más poder que la organización de ingeniería. Si a eso le sumas PMs que saben seguir procesos o frameworks pero no entienden realmente su producto ni a sus usuarios, se vuelve una pesadilla
Yo lo pienso en términos de proporciones
¿Cuál es la proporción entre ingenieros de frontend e ingenieros de backend? ¿Entre gerentes de ingeniería y colaboradores individuales? ¿Entre redactores de documentación técnica y el total de ingenieros? ¿Entre product managers y el total de ingenieros?
Y trato de ajustar finamente esas proporciones para maximizar el impacto y minimizar la interferencia y el micromanagement
Los números reales de esas proporciones variarán según la organización, pero si se percibe interferencia o si el “cómo” no surge lo suficiente de los propios ingenieros, hay que cambiar la proporción
Hay que aumentar la cantidad de ingenieros por cada people manager o product manager para que no puedan meterse de esa forma, obligarlos a priorizar en qué involucrarse y hacer que se retiren del terreno microscópico para devolverles a los ingenieros la autonomía sobre el método
Lo mismo aplica a QA, ingenieros junior, ingenieros senior, arquitectos, personal de HR, vicepresidentes y vendedores
Llevo más de 20 años en product management y estoy de acuerdo con la mayor parte de lo dicho aquí. Las proporciones importan
Para un CPO es fácil construir un imperio con un ejército de PM. La organización termina en un estado en el que los PM son dueños de pequeños fragmentos de la experiencia del cliente, como una sola página, y optimizan la tasa de clics de un botón, pero no contribuyen de manera significativa a la estrategia o la visión del producto
Es difícil ser product manager sin ser dueño de un producto
Los PM deberían enfocarse mucho más en los objetivos de negocio de lo que lo hacen hoy. Resolver problemas de los usuarios es necesario, pero no suficiente. Resolver ese problema también debe traducirse en valor para la empresa
Para que eso sea posible, son indispensables socios de ingeniería y UX con un fuerte sentido de producto
Peor aún, los desarrolladores “fácilmente reemplazables” vienen de empresas tercerizadas. Ahora hay que aislar el desarrollo del cliente con más capas de gestión
Una gran forma de aumentar el GDP
Por ejemplo, si trabajas con algo como ERP, Oracle Fusion Apps, WorkDay o SAP, un solo PM no puede ser dueño de todo el producto. En cambio, se encarga de varias funciones, cada una de las cuales es compleja por sí misma y, por la naturaleza de un ERP, normalmente también incluye integración con varios otros productos
Aun así, estoy de acuerdo con la idea general de que un PM debe ser dueño de algo significativo
Como desarrollador y gerente de desarrollo, los mejores product managers con los que trabajé casi no se metían en el “cómo”
Claro que pueden crear tickets a nivel de épica en el backlog, pero por debajo de eso confían en que tú y las personas a cargo del proyecto podrán sacar el trabajo adelante
El problema es que la organización tiene que respaldar eso. En la mayoría de las empresas, lo que más atención recibe no es lo guiado por visión o crecimiento, sino lo más ruidoso
Y ese tipo de trabajo muchas veces choca directamente con la dirección que quieren el responsable de producto o el manager
Los peores PM son los que no entienden el “cómo”, es decir, los PM que no saben cómo funciona su propio producto
Los mejores PM con los que trabajé tenían background técnico
Cuando la gente intenta pisar el terreno de otros, siempre termina en desastre. En ambas direcciones. Los ingenieros tienden a pensar demasiado desde el “¿cómo?”, por lo que son flojos en el “¿por qué?” y el “¿qué?”, y los product managers también deben apartarse del “¿cómo?” salvo que sea para aclarar el “¿qué?” o el “¿por qué?”
Tiene que haber equilibrio. Los PM/PO también necesitan una comprensión básica. No pueden ser personas que apenas sepan usar una computadora
Incluso un buen PM puede quedar bastante atado si está rodeado de demasiados PM mediocres
Trabajando con varias empresas Fortune 500 vi muchas culturas rotas
En esos lugares, los PM resuelven la mayoría de los problemas con la única herramienta que tienen: reuniones. Los incentivos de ascenso están diseñados para que, cuanto más grande sea la reunión, más importante parezcas
He estado en cientos de horas de reuniones de equipos cross-functional en las que en realidad trabajan 1 o 2 personas, por lo general el PM habla todo el tiempo, y 10 a 20 personas permanecen en silencio y al final solo dan su aprobación como para demostrar que existen
Como resultado, los equipos de ingeniería pierden motivación, se quedan sin tiempo para hacer trabajo técnico real y se les piden estimaciones o compromisos en el momento, sin investigar ni entender el código
También vi PM rechazar diseños técnicos porque no les gustaban los números o los “puntos”, y obligar a los ingenieros a reformatear la misma idea en otro “ticket” para satisfacer una estética desconocida del PM
Proyectos enteros se retrasan y se descarrilan por falta de comprensión y rituales inútiles de exhibición de estatus
En cambio, también trabajé con PM excelentes, que protegían al equipo de estas tonterías y lo ayudaban a enfocarse en los objetivos correctos. Esas personas son valiosas, y las anteriores son igual de dañinas
Independientemente de la cantidad de PM, esto trata sobre el tipo de PM con el que me gustaría trabajar
He trabajado en cuatro empresas del sector, desde startups de menos de 40 personas hasta JP Morgan Chase
Rechazo la idea de que una persona “técnica” sea más inteligente que una “no técnica”. De hecho, como ingeniero, muchas veces me pierdo en los detalles y dejo de ver el panorama general, y a menudo necesito que un PM me saque de ahí
Dicho eso, en mi experiencia, los PM con los que es más fácil trabajar como ingeniero son quienes han tenido aunque sea un poco de exposición real al código
No tiene que ser nada impresionante. Puede ser que hace mucho hayan creado un sitio web con HTML y CSS, que hayan escrito consultas SQL temporales, o que hayan tomado una clase de Python durante una maestría
Basta con que haya algo que les permita entender que escribir código no es ni una ciencia exacta ni magia pura
Estos PM defienden a los ingenieros con los que trabajan, o al menos intentan equilibrar las necesidades del negocio con la realidad de ingeniería
Las personas que llegan a ser PM sin ninguna exposición técnica tienden a estar más “orientadas al negocio”, y puede que eso sea exactamente lo que el negocio necesite en cierto momento, pero no siempre es así. Como ingeniero, quiero trabajar con alguien que también entienda mejor mi perspectiva
Para nada estoy resentido :p