El rol de product manager es un error
(sollecitom.github.io)- Cuando una empresa de software de producto malinterpreta product-led como “una estructura donde el PM toma todas las decisiones”, termina aplicando a PMs de carrera comunes un modelo que solo encaja con líderes fundadores excepcionales
- En un esquema donde una sola persona controla el producto, lo importante no es tanto el modelo en sí sino a quién se le entrega, porque presupone una figura poco común con visión, carisma, capacidad técnica y convicciones fuertes
- Cuando se le da demasiado poder a un PM común, los datos, los frameworks, los procesos de aprobación, las reuniones y las estructuras de roles dejan de ser herramientas de criterio y se convierten en un escudo para evadir responsabilidades y hacer política
- Esta dinámica termina alejando a la gente sobresaliente, y la empresa queda atrapada en tareas de bajo riesgo y procesos internos, perdiendo visión y talento
- La alternativa no es una estructura centrada en el cargo de PM, sino reunir en un mismo equipo a personas obsesionadas con la técnica y la calidad en cada área, para abordar juntas descubrimiento de producto, observabilidad, ingeniería, diseño, negocio y conocimiento del dominio
El problema de confundir product-led con un esquema monopolizado por PM
- En muchas empresas de software de producto, quienes fundan la compañía suelen ser personas más hábiles para levantar capital y entender la industria objetivo que para construir software de producto en sí
- Esos fundadores inician la empresa apoyándose en su experiencia y sus relaciones en la industria, pero si dirigen personalmente todas las decisiones, la confianza del experto de dominio puede terminar perjudicando a la empresa
- Algunos fundadores reconocen que ellos mismos pueden ser un riesgo y contratan a alguien para delegarle la toma de decisiones
- Ahí aparece el malentendido de que “no debemos ser una organización de servicios sino una empresa de producto, y una empresa de producto debe ser product-led, así que el PM tiene que hacerse cargo”
- Aquí product-led no significa que el PM tome todas las decisiones
- Cuando surge una objeción, suele aparecer la respuesta de que grandes empresas como Amazon, Apple o Tesla también delegan el control en una sola persona
- Muchas grandes empresas sí ponen el control en manos de un solo individuo, pero no todas las grandes empresas usan ese mismo modelo
Lo que presupone el modelo de un solo tomador de decisiones
- Un modelo que entrega el control de la empresa a una sola persona no es incorrecto por definición; su éxito o fracaso depende de a quién se le da
- Figuras como Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel o Leonardo reciben admiración masiva por su visión, carisma, confianza, resiliencia y excelencia
- Son personas capaces de imaginar una realidad alternativa, entregarse por completo a su trabajo y producir grandes cambios por pura voluntad
- Si una persona así realmente existe, el modelo de control unipersonal puede funcionar con enorme fuerza
Las personas excepcionales no son PM comunes
- Esas grandes figuras no eran product managers
- Eran artistas, matemáticos, inventores, científicos, CEOs, y en algunos casos ocupaban varios roles a la vez
- No estaban obsesionados con OKR, KPI, datos ni con la opinión de otros, sino con su propia visión y capacidad técnica
- Una figura excepcional puede tener opiniones fuertes, un gran ego, una manera propia de hacer las cosas, asperezas personales y desprecio por la mediocridad
- Justamente por esas características suele ser difícil contratarla en una empresa normal, y probablemente tampoco quiera trabajar en la mayoría de las empresas
- Si puedes encontrar a una persona realmente extraordinaria, no estorbarla y soportar su intensidad, entonces sí puedes darle el control del producto y de la empresa
- En la práctica, encontrar a alguien así es difícil, puede que no quiera trabajar contigo, o que la empresa no soporte ni su ego ni su intensidad
Qué pasa cuando se aplica a PMs comunes una estructura pensada para figuras extraordinarias
- El error más grande es adoptar un modelo operativo que requiere una figura excepcional sin tener realmente una figura excepcional
- Se critica que los PMs de carrera que la empresa puede contratar cómodamente normalmente no están a ese nivel
- Se los describe como lacayos del negocio, fanáticos de frameworks, expertos temáticos, excreadores que subieron la escalera corporativa, adictos a las métricas o egresados de MBA
- Si una empresa entiende “product-led” como “el PM toma todas las decisiones” y contrata a un PM de carrera bajo esa lógica, el resultado puede ser fatal
- Como a estos PMs les faltan visión, carisma, expertise, convicciones fuertes y capacidad técnica, tienden a moverse de forma segura y actuar políticamente
- Al ser conscientes de sus propias limitaciones, repiten conductas orientadas a quedarse con el mérito y esquivar la responsabilidad
Cómo los datos y los procesos se convierten en mecanismos de defensa
- La primera etapa es la instrumentalización de la toma de decisiones basada en datos
- Se ignora que es posible encontrar datos para respaldar casi cualquier postura y se presenta la propia decisión como la única racional según los datos
- Cuando algo sale mal, se culpa al mercado, a la calidad de los datos o a la mala suerte de la empresa, y se afirma que no fue responsabilidad propia
- La siguiente etapa es introducir frameworks y roles para todo
- Aparecen frameworks de carrera de 18 niveles, evaluaciones trimestrales de desempeño, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe, etc.
- No seguir el proceso, no estar guiado por datos, tener poca documentación o no tenerla actualizada se vuelve motivo de reproche
- Dentro de la organización surgen roles como Director of KPIs, Deputy Director of Product Operations o Global Head of Digital Whiteboard Solutions
- Todo empieza a requerir aprobación, y ninguna persona controla por completo ningún proceso o área
- En los grandes comités cualquiera puede decir “no”, pero nadie puede decir completamente “sí”
- Las reuniones también se disparan
- Aumentan los reportes de estado, reuniones de alineación, 1:1, staff meetings, discusiones estratégicas, sesiones de contexto, go/no-go de release y reportes de proyecto
- La etapa final es contratar a muchas personas malas
- Se contrata según si representan o no una amenaza, y cualquier rastro de excelencia se convierte en motivo de rechazo
- La persona ideal para contratar pasa a ser alguien todoterreno que cumple más o menos lo que se le pide sin oponerse ni preocuparse por la calidad
- El número de PMs se dispara, aparecen capas de PM por equipo y por área, y el mismo comportamiento se replica una y otra vez
Lo que pierde la organización
- Una vez que comienza esta dinámica donde la gente común concentra poder, la gente sobresaliente tarde o temprano se va
- O la desplaza un dictador mediocre, o se termina yendo por no poder soportar el entorno
- El ritmo del trabajo se detiene, y ejecutar cualquier cosa se vuelve doloroso, una gran promesa y un intento arriesgado
- Las visiones ambiciosas se tratan como algo irreal y se descartan rápidamente
- Lo que la empresa hace queda limitado a frutos al alcance de la mano y decisiones seguras
- Incluso quienes no sienten una gran pasión por su técnica sufren y se van, mientras que quienes se quedan por pura insensibilidad empeoran aún más el problema
- La empresa pierde a su mejor talento, olvida su visión, se vuelve inward-looking y termina vacía de sentido
- En el mejor de los casos muere en algún momento; en el peor, sobrevive a medias convirtiendo a personas apasionadas en zombis que odian su propio trabajo
La alternativa: un equipo de personas extraordinarias en lo cotidiano
- Hay otra forma de construir una empresa de producto exitosa además de encontrar a una figura excepcional, contratarla, darle el control y soportar su intensidad
- La alternativa es contratar a personas extraordinarias en lo cotidiano
- Cada una debe destacar en algún ámbito
- Debe estar obsesionada con su oficio y moverse por la calidad
- El equipo debe formarse de modo que las áreas de excelencia de sus integrantes se superpongan lo menos posible
- En lugar de fragmentar demasiado la responsabilidad individual, hay que dejar que hagan con entusiasmo lo que aman y que pongan su tiempo y su habilidad al servicio de la empresa
- Estas personas también pueden ser desafiantes, tercas, egoístas, raras o cambiantes
- Si se les dan buenos problemas y se les permite hacer un gran trabajo, se comprometen por completo con el éxito de la empresa
El lugar que deberían ocupar los líderes y los PM
- No hace falta renunciar por completo a la idea de liderazgo; incluso se podría eliminar la figura de team lead y dejar leads de área como coordinadores entre lo externo y lo interno
- Si se asigna una persona responsable por cada área, ese rol debe recaer en alguien cercano a una gran figura excepcional
- Es decir, alguien más parecido a Jobs, Musk o Bezos en visión, carisma, intensidad, pasión y conducta extrema
- Si se pone al frente a alguien cómodo en el corto plazo, obediente y que exige poca atención, existe el riesgo de caer en la situación descrita antes
- Se plantea que el rol tradicional de PM no tiene lugar en una empresa que funciona bien
- Aun así, sí hacen falta personas obsesionadas con áreas tradicionalmente asignadas al PM, como descubrimiento de producto u observabilidad de producto
- Esas personas pueden haber tenido el título de PM antes, y eso en sí no es un problema
- La razón para contratarlas no es el título sino su obsesión y sus fortalezas
- En vez de ubicarlas en un rol separado de PM, se las integra en un mismo equipo junto con personas obsesionadas con ingeniería, diseño, performance, negocio y conocimiento del dominio
No es un problema exclusivo de los PM
- Si alguien sin visión, carisma, pasión, capacidad técnica ni fuerza de voluntad queda a cargo, aparece el mismo problema
- El foco en los PM se debe a la tendencia, dentro del desarrollo de software de producto, a poner como responsable a alguien con el título de product manager
- Algunos PMs sí son realmente excepcionales y podrían desempeñarse muy bien en ambos modelos
- Pero eso no significa que necesariamente lo hagan mejor que otras personas brillantes con trayectorias distintas
- Esos PMs son una minoría diminuta, y se sostiene que la mayoría de los PMs de carrera ni se acerca a poder liderar desde la excelencia
1 comentarios
Opiniones de Hacker News
En mi empresa actual hay mucha gente inteligente, pero por varias razones no tenemos gerentes de producto, y como resultado, el trabajo que debería hacer un gerente de producto simplemente no se hace.
Casi no hay ingenieros que quieran encargarse de mantener relaciones con clientes, hacer entrevistas con usuarios, descubrir funciones potenciales, convencer al liderazgo o hacer política para la asignación de recursos.
En mi empresa anterior, 2 de 3 gerentes de producto eran incompetentes y los despidieron, pero 1 era realmente excelente, y con solo parte de su tiempo logró en un año más de lo que mi empresa actual ha conseguido en más de 2 años.
Estoy de acuerdo en que no hay suficientes buenos gerentes de producto. Creo que la cantidad de personas que pueden ser buenos gerentes de producto crece linealmente con la población, pero la industria del software explotó exponencialmente, así que ahora se necesitan 100 veces más roles de PM que la cantidad de PM realmente excelentes.
Tampoco eran técnicos, así que no gestionaban tickets de Jira, y la gestión del liderazgo en general quedaba a cargo de los managers.
Creo que esos gerentes de producto principalmente iban a reuniones, hablaban con el liderazgo, hablaban con ingenieros, escribían documentos y dirigían reuniones de planificación de sprint que se hacían eternas.
Un gerente de producto que se ocupe de clientes, usuarios y problemas de recursos podría ser mucho más valioso.
Seguía escuchando “somos una empresa engineering-first”, pero en la práctica eso significaba que los equipos de ingeniería perseguían por su cuenta la tecnología más nueva.
Hay 3,5 productos principales, en realidad 4,5, cada uno hecho con un stack tecnológico distinto, y además hay unos 8 productos más que debemos soportar por requisitos legacy. No hay estandarización ni interoperabilidad entre productos, ni transferencia de conocimiento, así que los costos de desarrollo están por las nubes.
Este año, en dos ocasiones, tuve que explicarles a ingenieros con 20 años en la empresa por qué está mal que una API use solo TLS 1.3, otra use 1.x y otra ni siquiera requiera TLS.
Los clientes nos odian. En mi producto escribieron primero el material de marketing y dejaron que los ingenieros lo construyeran como pudieran. Una sola etapa para mover datos de Oracle a parquet terminó hecha en tres lenguajes y con dos bases de datos intermedias (MySQL y PG), y apenas logré impedir que también metieran Redis.
Por suerte, hace 2 años nos compró un fondo de private equity y ahora recibimos el ultimátum de que, si no generamos dinero, se acabó. Era un centro de costos de una empresa de 20 años que nunca había ganado dinero, y aunque no alcancemos los objetivos, creo que el universo estará mejor si desaparece el desastre de diseño de software que construimos.
Un gerente de producto tonto se convierte en una especie de project manager que solo da seguimiento a otro libro de tareas, mientras que uno inteligente entiende profundamente el negocio y asciende o se va.
También es un rol difícil de gobernar. A veces se lleva mucho crédito por el trabajo de otros, y otras veces no recibe ningún reconocimiento y su carrera se estanca.
Si se le encarga este rol a ingeniería, a la gestión de ingeniería o a la gestión general, se debilita la capacidad de ingeniería. Si vas a contratar ingenieros, deberías seleccionarlos por esa capacidad y protegerlos de la gente externa; pero si el equipo también tiene que manejar todas esas interacciones, terminas contratando personas con habilidades mixtas y, al final, se diluye el lado de ingeniería.
Mantener deliberadamente ajustada la capacidad de los gerentes de producto puede servir como mecanismo de presión para que se enfoquen en el nivel alto y la visión, y para evitar que se metan demasiado en los detalles, creen procesos inútiles o definan funciones en exceso.
En la industria tecnológica inflada durante más de 10 años por el crecimiento con tasas de interés bajas, mucha gente pudo tener éxito simplemente con presentarse a trabajar.
Es un texto confuso. Dice que “hay que eliminar el rol de PM”, pero también que “sigue haciendo falta alguien dedicado a hacer el trabajo que hacía el PM, solo que no lo llamemos PM y digamos simplemente que es una persona común y excepcional”.
Parece que el autor tuvo una mala experiencia con un PM, y lo de los MBA deja ver esa huella; por eso da la impresión de que quiere tirar al bebé junto con el agua de la bañera.
Cuando el negocio crece, aparece la especialización de roles y se vuelve necesaria. Hay PM pésimos y es un trabajo difícil, pero si nuestro equipo perdiera a su PM, sería realmente decepcionante.
Puede que yo solo haya tenido buenas experiencias con PM, pero en nuestra empresa los PM averiguan qué quieren los clientes y qué debe ofrecer el producto, y junto con el engineering manager equilibran qué es técnicamente posible y qué capacidad hay para implementarlo.
Si el engineering manager dice “con este calendario es imposible”, el PM encuentra un plan alternativo para el producto.
Este texto parece saltarse el paso intermedio y simplemente querer cambiarle el nombre sin motivo.
¿Quién exactamente se supone que decide qué problemas debe priorizar el equipo? Esa es justamente la responsabilidad central del rol de PM.
Al final, parece que tuvo una mala experiencia con un PM que no supo tomar esa decisión de prioridades.
Aun así, por esa persona tuve que estar en la reunión más incómoda a la que he asistido: durante una hora, de principio a fin, dejó claro frente a un gerente de mayor nivel que no entendía en absoluto el producto, mientras ese gerente sí lo entendía.
Los buenos PM ayudan mucho porque entienden qué quieren los clientes, qué podemos ofrecer, los calendarios realistas y cómo tratar con el área legal y los stakeholders de negocio. Yo los ayudo cuando necesitan validar el lado técnico.
Rara vez a un equipo le faltan ideas para construir o formas de mejorar la experiencia del producto y de operaciones. Un product manager es quien intenta que se construya lo correcto.
Soy PM con 20 años de trayectoria en IT, y estoy considerando un MBA para adquirir conocimientos y una comprensión formal de negocios que me ayuden a crecer en el futuro.
Los PM parecidos a mí no empiezan, apenas obtienen un MBA, a jugar —usando una expresión militar— a hacer tonterías.
El problema son las personas que van directo de la preparatoria a la universidad, al MBA y a un puesto de gestión. Muchas no tienen ni un día de experiencia de campo, salvo quizá una pasantía breve a mitad de la carrera.
Es un texto raro. Usa muchas palabras, pero al final parece decir simplemente: “si contratas gente de bajo rendimiento, eso perjudica a la empresa”.
La alternativa también es algo como “contrata gente buena, pero no para el rol de PM”.
Se lee como algo escrito por alguien que tuvo una mala experiencia con un PM que se creía Steve Jobs. Los PM son personas normales; no entiendo por qué asumir que todos los que tienen ese título son personas con sentido de privilegio.
En una organización puede haber miles de PM, y cada uno tiene su jefe. Es simplemente un texto raro.
Es como: “no contrates product managers, porque no serán personas excelentes. En su lugar, contrata personas excelentes, ¡y no una sola, sino todo un equipo!”.
Contratan gente de bajo rendimiento todos los días y no sé por qué. Creo que un chimpancé sin entrenamiento con un montón de currículums tendría mejor tasa de acierto.
Un PM satisface una necesidad muy concreta. Esa necesidad es difícil de cuantificar, pero se puede decir que, sin un buen PM, todo se viene abajo.
Normalmente recopila información de los usuarios sobre qué funciona y qué no, escucha de los ejecutivos qué necesita la empresa para operar, entiende hacia dónde va la industria hablando con líderes del sector, trabaja con diseño y depura todo eso hasta convertirlo en funcionalidades que realmente hay que construir.
También trabaja con ingeniería para determinar qué es práctico y cuánto podría tardar aproximadamente, elimina funciones que consumen mucho tiempo pero aportan poco valor, y ayuda a que las estimaciones y la velocidad del equipo sean más o menos predecibles.
Con eso ya estoy describiendo el trabajo de 1,5 personas. Si eliminas la organización de producto, todo ese trabajo se distribuye entre el equipo de ingeniería, y no todos los miembros del equipo son buenos en eso.
Incluso si logras equilibrarlo, cuando una persona se va, aparece un vacío invisible que ni siquiera estabas buscando cubrir al contratar.
Parece que muchos equipos quedaron marcados por organizaciones de producto disfuncionales. Esas organizaciones están desconectadas, o parecen no tener interés, en los clientes, la industria y la organización; en cambio, queman una enorme cantidad de tiempo en reuniones para iterar mockups, micromanagean a los diseñadores hasta hacer que la gente buena se vaya y mantienen a los ingenieros atrapados en reuniones de producto innecesarias.
El PM trabaja estrechamente con el equipo para definir el roadmap y priorizar el trabajo que tendrá mayor impacto para los clientes y el negocio.
Cuando un PM hace bien su trabajo, los ingenieros entienden con mucha claridad qué problema deben resolver después y por qué.
En segundo lugar, también importa si tiene la posición dentro de la organización para comunicarse con la alta dirección sobre el proyecto. Si tiene ambos atributos, está en buena forma.
Lo que aprendí tras trabajar más de 12 años en la industria tecnológica es que los roles no son más que una forma de expresar los deseos de una organización.
Si quieren que alguien piense en el producto, abren un puesto de PM; si quieren un líder de equipo, crean un puesto de gerente de ingeniería.
Los títulos son elementos ficticios que nos permiten jugar el RPG del trabajo desde distintos ángulos. Al final, lo que llevamos al trabajo es la combinación única de talentos y experiencias de cada persona.
Algunas personas suelen cruzar esos límites de rol, y está bien. Tienen ideas y hasta pueden inventarse su propio título.
Las organizaciones deberían ser lo bastante inteligentes como para dejar que esas personas crezcan y prosperen. No significa que no puedas tener éxito como PM ni hacer un gran trabajo; significa que, como las organizaciones normalmente no invierten suficiente tiempo en conocer a fondo a la persona que incorporan, ofrecen roles precocinados.
Un ingeniero también puede hacer el rol de PM, pero no piensa todo desde la perspectiva de PM. Porque su identidad principal no es la de PM, sino la de ingeniero.
Otra cosa que entendí en el contexto de cruzar los límites de los roles es que, por lo general, la parte más valiosa del rol de una persona son las responsabilidades que no están definidas explícitamente.
Es difícil de explicar, pero muchas veces la gente aporta valor de maneras difíciles de describir o cuantificar.
En general es una postura bastante dura, pero definitivamente tiene partes ciertas. Cuando dentro de una empresa aparece una organización de producto, tiende a derivar hacia comités, OKR, ciclos de revisión, planes y mucha burocracia, tal como describe el autor.
Antes, en un rol de ingeniería de ventas de cara al cliente, estaba impulsando el producto con muchísimo éxito a través de la influencia, y acepté ingenuamente un puesto de product manager pensando que tendría control formal.
Cuando me senté ahí, resultó ser un trabajo de oficina extremadamente restringido y no encajaba para nada conmigo. Casi todo era administrar tickets y backlog, coordinar en lugar de tomar decisiones, y preparar interminables reportes en PowerPoint; lo más creativo era diseñar el proceso con el que la empresa formalizaría el roadmap de producto. Huí a los 6 meses.
Esta función es bastante útil para dar visibilidad sobre lo que se está construyendo y gestionar las prioridades en conflicto de un producto en crecimiento. Pero no consiste en dar forma ni controlar la dirección en que evoluciona el producto.
Es una función de ordenar, filtrar y, con suerte, recopilar datos; crea un rastro auditable de decisiones y la impresión de una toma de decisiones madura para que los MBA de arriba duerman un poco más tranquilos.
Normalmente hacía entre 4 y 12 propuestas de nuevas funcionalidades (PRD) al mes, según el tamaño de la empresa y la cantidad de proceso necesaria.
La forma siempre era: “Los usuarios actualmente tienen el problema X, y para resolverlo deberíamos construir Y. Y se ve así…”.
Claro que hay dificultades de coordinación y comunicación, pero siempre se trataba de averiguar qué construir después.
Entiendo que no todos los roles de PM sean así, pero no estoy de acuerdo con que el PM no pueda ser más que “ordenar/filtrar/teatro de madurez en la toma de decisiones”.
Si el rol fuera simplemente ordenar el backlog existente, me preguntaría quién definió los elementos nuevos que entraron al backlog.
Estoy de acuerdo en que una organización de producto puede convertirse en una entidad política y burocrática, en lugar de una función de apoyo.
Personalmente creo que los roles de producto deberían estar integrados dentro del equipo de ingeniería y reportar al mismo líder. El nivel puede debatirse, pero así un mal PM puede tratarse igual que un mal ingeniero.
Por supuesto, si la empresa tampoco puede despedir a malos ingenieros, entonces hay otro problema.
El autor no ofrece demasiado framework para eso.
La solución del artículo huele a teoría del gran hombre.
La parte final de “las personas increíbles imaginan realidades alternativas, se entregan por completo al trabajo y mueven montañas con fuerza de voluntad” es demasiado reduccionista.
Quienes mueven montañas no son la fuerza de voluntad, sino las personas de abajo que realmente implementan la visión. En el mejor de los casos, esa “gran persona” solo alinea incentivos para movilizar a quienes ejecutan de verdad y a los expertos.
Trabajo actualmente en una gran empresa tecnológica que casi no tiene roles de PM, así que puedo hablar de cómo se siente directamente.
Hasta ahora es mixto. También trabajé en organizaciones con muchos PM, y estoy de acuerdo en que esas organizaciones no son muy buenas. Pero, al final, el trabajo que haría un PM sigue siendo necesario.
En nuestra organización, esa responsabilidad recae formalmente en los managers de software y en desarrolladores senior o superiores.
Por ejemplo, si como ingeniero senior lideras una iniciativa del equipo, debes encargarte de todas las actividades que haría un PM. Otras actividades las toman el manager o el senior manager.
Desde el punto de vista de un desarrollador, es bastante pesado. Como contribuidor individual tienes que sacar adelante tu propio trabajo, pero además coordinar a otras personas y asegurarte de que el trabajo se termine.
No solo es trabajo adicional; honestamente, muchos desarrolladores no tienen las habilidades para ser PM efectivos. Como hay que coordinar a personas con distintas líneas de reporte, la colaboración entre equipos también se vuelve difícil.
Este enfoque a menudo deriva en falta de ownership, falta de accountability, esfuerzos duplicados, cosas que se cuelan por las grietas y desorden general.
Dicho eso, funciona bien para iniciativas pequeñas dentro de un equipo con pocas personas involucradas. Porque elimina el overhead de PM y da el control a quienes construyen. Pero no estoy seguro de que también encaje para iniciativas más grandes.
Es cierto que muchos desarrolladores no tienen habilidades para ser PM efectivos, pero, para ser justos, muchos PM tampoco tienen habilidades para ser PM efectivos.
La dificultad de coordinar con personas que tienen otra línea de reporte también aplica igual para los PM.
La diferencia clave parece ser el juicio sobre “si vale la pena separar este trabajo en un rol dedicado”. Yo tiendo a pensar que, para los ingenieros, casi nunca vale la pena.
Con solo ver el título, ya estaba listo para odiarlo. Pensé que sería el típico texto de “los PM son tontos y en una empresa solo hacen falta ingenieros inteligentes que dominen el mundo”
Pero no era ese tipo de artículo, y creo que identifica el problema casi a la perfección
Sin embargo, la solución desaparece como con un pase de manos. Es algo así como: “contrata a personas normalmente grandiosas, cada una excelente en algo, obsesionada con su oficio y movida por la calidad; júntalas en equipos y haz que trabajen sin responsabilidad individual”
Suena bien, pero ¿quién puede dar un ejemplo real en el que este enfoque haya funcionado en una empresa de más de 100 personas? No sé cómo podría funcionar en la práctica
Valve hace, o al menos hacía, algo muy parecido. Su manual para empleados[0] antes aparecía mucho en HN, pero últimamente no tanto. Me da curiosidad si a ellos les está funcionando bien
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
El autor parece haber trabajado con gerentes de producto realmente mediocres. Soy PM con formación autodidacta en ingeniería, y he visto a mucha gente mediocre en varias áreas
Veo mi trabajo principalmente como gestión de riesgos. Incluso un equipo de grandes ingenieros y diseñadores enfrenta muchos riesgos al lanzar un buen producto
Puede que no tengan la habilidad de explicar una visión para convencer a otros, o que el equipo legal imponga requisitos o restricciones sobre lo que se puede y no se puede hacer
Mi trabajo es gestionar esas cosas para sacar lo mejor del equipo y ayudarlo a concentrarse en lo que de verdad importa: crear y lanzar un buen producto
Mido el éxito por qué tan innecesario me vuelvo. El objetivo es que no me necesiten: que el equipo tenga el contexto, la confianza y el apoyo para tomar buenas decisiones sin mí
Me gusta trabajar con ingenieros para que desarrollen esas capacidades, y junto con mis socios gerentes de ingeniería entender las fortalezas, debilidades y metas de cada ingeniero para encontrar formas de que crezcan
Entiendo el argumento de que, en una utopía ideal, quizá yo no sería necesario. Pero en la mayoría de los casos, para hacer un trabajo realmente excelente hay que enfrentar desafíos y riesgos, y un buen PM es un agregador neto de valor que colabora con el equipo para superarlos
Se trata de asegurar que el equipo tenga el contexto, los requisitos, los insights, las métricas, los objetivos, etc. necesarios para hacer su mejor trabajo, y que entienda qué problema debe resolver, para quién y por qué
Un buen PM crea un entorno tan bien preparado que los ingenieros pueden pensar: “el PM no hace nada, así que no hace falta”. Ese juicio es miope y, francamente, insultante