¿Product Manager?
Las cualidades que la IA no reemplaza — y si este trabajo te va a gustar
Patrick T. Hoffman
En 2015 podías entender el product management en un fin de semana largo. Leías un par de posts — Shreyas Doshi sobre pensamiento sistémico, Ken Norton sobre cómo contratar PMs, los viejos ensayos de Joel Spolsky sobre trabajar con ingenieros. Acompañabas a un PM en alguna empresa que te dejara observarlo. Escribías un PRD mal, y después menos mal. Aplicabas a vacantes. Conseguías una.
Ese camino ya no existe. No porque los posts estuvieran equivocados. Porque el trabajo se movió.
No me refiero a que se movió el título del puesto, ni a que cambiaron las bandas salariales, ni a que reorganizaron los organigramas. Me refiero al trabajo en sí — aquello a lo que dedicas tus horas, la habilidad que te gana un lugar en la mesa, la razón por la que una empresa emplea a un PM en vez de dejar que ingenieros y diseñadores tomen las decisiones de producto por su cuenta. Ese trabajo es sustancialmente distinto hoy de lo que era hace diez años, y será todavía más distinto para cuando termines de leer esto.
Déjame ser específico sobre qué se movió y por qué, porque las afirmaciones vagas de que la IA lo cambia todo no te ayudan a decidir nada.
Qué cambió en realidad
Un PM junior en 2015 dedicaba buena parte de su día a tareas que exigían habilidad, pero no juicio: redactar criterios de aceptación detallados, armar matrices comparativas de la competencia, sacar analítica básica de producto, sintetizar notas de investigación de usuarios, hacer wireframes en Balsamiq o Sketch, escribir tickets. No eran tareas triviales. Bien hechas, comunicaban claridad. Mal hechas, generaban confusión. Pero se podían aprender, y aprenderlas era la manera de desarrollar el músculo para hacer, con el tiempo, el trabajo más difícil.
Esa escalera prácticamente desapareció. Un PM junior con acceso a un buen asistente de IA — y en 2026 todo PM tiene acceso a un buen asistente de IA — puede producir en una tarde lo que antes tomaba un mes. El análisis competitivo que antes requería horas de investigación estructurada: redactado en veinte minutos. La síntesis de cincuenta transcripciones de entrevistas con usuarios: lista. Los flujos de prototipo: generados. La estructura del PRD: armada. La calidad del resultado varía; todavía hay que editar, juzgar y refinar. Pero el volumen de tiempo dedicado al trabajo de producción se desplomó.
Esto suena a ganancia pura. En parte lo es. Pero considera qué desplazó.
Ese trabajo de producción era la escuela de los PMs. Aprendías qué preguntas importaban escribiendo cincuenta tickets y notando cuáles ignoraban los ingenieros. Aprendías qué decían realmente los usuarios — no lo que querías que dijeran — pasando diez horas leyendo transcripciones de entrevistas. Aprendías dónde estaban las costuras arquitectónicas de tu producto dibujando cada caso borde en un diagrama de flujo. El tedio era el plan de estudios. Las horas eran la formación.
Los PMs junior que entran hoy a la profesión se saltan casi todo ese plan de estudios. Van directo al resultado. Y el resultado se ve competente — muchas veces lo es — pero puede ser competente sin que la persona que lo produce entienda por qué es competente, ni sepa corregir el rumbo cuando deja de serlo.
Esto es lo primero que cambió: el aprendizaje de oficio se rompió.
El poder se movió — pero no hacia los PMs
Aquí viene la parte de la conversación sobre IA y PMs que casi todo el mundo entiende mal: se asume que la IA empodera a los PMs frente a sus compañeros de equipo. No es así. Empodera a todos más o menos por igual, lo que significa que las viejas ventajas del PM ya no se sostienen como antes.
Un PM en 2018 tenía una ventaja estructural de información. Eras la persona que había leído la investigación de usuarios y las métricas del negocio y el panorama competitivo. Tus ingenieros eran expertos en el código; tus diseñadores, expertos en patrones de interacción; tus data scientists, expertos en el modelo. Tú eras el generalista de la sala. Ese generalismo era palanca.
Ahora tus ingenieros pueden llegar por prompts a un análisis competitivo en quince minutos. Tus diseñadores sacan su propia analítica. Tus data scientists escriben sus propios resúmenes de historias de usuario. La IA le dio a todos acceso al trabajo de recolección de información que antes justificaba la presencia del PM en la sala.
Lo que esto significa es que las partes del trabajo de PM que siempre fueron invisibles — el juicio, la convicción, la disposición a equivocarte frente a otros y seguir adelante — ahora son todo el trabajo. El andamiaje que rodeaba esas partes invisibles, y que en cierto modo las ocultaba, ya no está. Te quedas de pie en una sala, y la pregunta es: ¿puedes hacer de verdad lo que importa?
Lo que importa es decidir. No en el sentido de tener la autoridad para decidir — eso es política organizacional, otro problema distinto. Decidir en el sentido de tomar una pila de información incompleta y contradictoria y colapsarla en una dirección que estés dispuesto a defender. La IA es extraordinariamente buena generando opciones. No es buena eligiendo. En esa asimetría vive el valor del PM moderno.
Por qué escribí este libro
Llevo camino de quince años como PM. Lo he sido en startups tan chicas que «el equipo de producto» era yo y un archivo de Figma compartido. Lo he sido en empresas tan grandes que mis métricas corrían sobre infraestructura que servía a miles de millones de personas. He hecho PM de hardware — objetos físicos reales que existían en el mundo y se rompían de maneras en que el software no se rompe, con cadenas de suministro y tolerancias y esa ansiedad particular de saber que un defecto en tu spec se va a fabricar en diez mil unidades antes de que lo detectes. He hecho PM de productos regulados en ciudades con opiniones firmes sobre qué podía circular por sus calles y a qué velocidad. He hecho PM de plataformas para comerciantes que no eran ingenieros ni querían serlo, que solo necesitaban que el comercio funcionara.
Cada uno de esos contextos me enseñó algo distinto sobre lo que el trabajo realmente es. No lo que dicen los blogs de PM. No lo que dicen las descripciones de puesto. Lo que realmente es — su textura, las partes que se sienten bien y las que te drenan, las habilidades que resultan importar y las que resultan ser teatro.
Durante más de una década, la gente me ha hecho dos preguntas: ¿es el product management una buena carrera?, y ¿cómo entro? Las he respondido cientos de veces — en conversaciones con mentees, en office hours, en hilos de consejos, al final de charlas. Las respuestas que he podido dar uno a uno llegan quizá a unos cientos de personas; la gente a la que esos mentees les pasan las ideas, a unos cientos más. Escribí este libro para escalar esas conversaciones más allá de lo que cualquier persona puede hacer en una sala o en una llamada.
La razón para escribirlo ahora, en específico, es que las rampas de entrada están cambiando. La IA angostó algunos caminos, simplificó otros y empezó a cambiar la naturaleza misma del trabajo de maneras que el canon existente de PM todavía no alcanza a registrar. La respuesta honesta a «¿debería ser PM?» se ve distinta hoy de como se veía hace apenas tres años. Quiero que quien se hace esa pregunta tenga una respuesta pensada — no la versión de marketing del puesto, no lo que dicen los posts, sino lo que el trabajo realmente es y si de verdad disfrutaría hacerlo.
Estaba cansado de ver a gente descubrir demasiado tarde que PM no era el trabajo que creía. No porque PM sea malo — yo he disfrutado la mayor parte, y creo que es uno de los oficios genuinamente interesantes de la tecnología — sino porque la brecha entre la versión de marketing del puesto y el puesto real es lo bastante grande como para ser un problema serio. Hay gente que acepta un rol de PM esperando construir y se encuentra viviendo en reuniones. Gente que lo acepta esperando autonomía y se encuentra negociando cada centímetro de espacio en el roadmap. Gente que lo acepta porque escuchó que es el camino a CEO — que, para la mayoría, no lo es, y la ruta que pasa por ahí es miserable si eso es lo que realmente buscas.
El modelo que tenía en mente era un libro llamado Architect? A Candid Guide to the Profession, publicado por MIT Press. Ese libro no te dice que la arquitectura es glamorosa. Te dice qué hacen los arquitectos todo el día, qué tipo de persona tiende a prosperar en ese trabajo, cuáles son las realidades económicas, qué se pierde de la versión romántica cuando realmente ejerces. Respeta al lector lo suficiente como para darle la información que necesita para tomar una decisión real. Yo quería escribir ese libro para el product management.
Este libro intenta hacerlo.
La pregunta que este libro responde
No es: ¿cómo me convierto en PM?
Para eso hay docenas de recursos. Cursos, bootcamps, guías de preparación de entrevistas, portafolios de casos de estudio que se supone que armes, entrevistas simuladas con gente que trabajó en Google y te cobrará cuatrocientos dólares la hora por explicarte qué significa CIRCLES. Ese ecosistema existe y te servirá si lo que buscas es ayuda táctica para que te contraten.
Este libro responde una pregunta distinta: ¿de verdad quieres este trabajo?
Suena obvio. Claro que lo quieres — ¿por qué más estarías leyendo sobre él? Pero querer un puesto y querer hacer el trabajo del que ese puesto se compone son dos cosas distintas, y confundirlas sale caro. Caro en tiempo. Caro en ese agotamiento particular que produce hacer un trabajo que no te queda. Caro en costo de oportunidad — todo lo que no hiciste mientras fracasabas en convertirte en PM, o mientras lo lograbas y lo odiabas.
El libro de Architect? pregunta: ¿te gusta el trabajo, los problemas, la persona en la que te conviertes haciéndolo? Ese es el encuadre correcto. Las profesiones no solo te dan un salario y un título. Moldean cómo piensas, qué notas, qué te importa, en quién te conviertes al cabo de una década. La mejor PM que conozco piensa en todo como un problema de diseño de incentivos y comportamiento de usuarios — en un restaurante, mirando una cuadra de la ciudad, leyendo una noticia. Eso le hicieron a su pensamiento quince años de PM. No es un disfraz; es una reestructuración.
Así que la pregunta no es si PM es una buena carrera. Es si es una buena carrera para ti — para tu estilo cognitivo, tu tolerancia a la ambigüedad, tu relación con la autoridad, tu necesidad de autoría creativa visible. Y la única manera honesta de responderla es mostrarte cómo se ve el trabajo de verdad, de cerca, un martes a las 2 de la tarde cuando el sprint va atrasado, el stakeholder está molesto y los datos se contradicen entre sí.
Eso es lo que este libro intenta hacer.
Lo que PM no es
Antes de describir qué es el product management, necesito despejar el terreno de las cosas que no es, porque las ideas equivocadas son tan persistentes que, si no las atiendo desde el principio, van a teñir cómo lees todo lo demás.
Los PMs no son mini-CEOs. Sé que este encuadre está en todas partes. Lo escribió Ben Horowitz. Lo cita cada descripción de puesto de PM. Es la idea más dañina de todo el product management, y quiero ser claro sobre por qué.
Un CEO tiene autoridad formal. Puede contratar y despedir. Puede reasignar presupuesto. Puede revertir decisiones. Rinde cuentas a un consejo, lo que significa que tiene ante quién responder de una manera que tiene dientes. Un PM no tiene nada de eso. Un PM le rinde cuentas a todos y tiene autoridad sobre casi nadie. El PM «es dueño» del producto en el sentido de que es responsable de sus resultados — pero no controla a los ingenieros que lo construyen, ni a los diseñadores que le dan forma, ni a los data scientists que lo instrumentan, ni al equipo legal que lo acota, ni a los ejecutivos que en última instancia lo financian.
El encuadre del mini-CEO es seductor porque suena empoderador. Lo que hace en realidad es montar un desajuste entre responsabilidad y autoridad que aplasta a quien no está preparado. Si entras a PM esperando ser CEO, vas a pasar tu carrera confundido y frustrado por la brecha entre lo que crees que debería ser cierto (soy dueño de esto, por lo tanto decido) y lo que es cierto (soy dueño de esto, por lo tanto respondo cuando otros deciden mal).
El modelo mental correcto no es CEO. Se parece más a editor. Un gran editor no escribe el libro. Entiende qué intenta ser el libro, ayuda al autor a llegar ahí, toma decisiones difíciles sobre qué cortar y qué desarrollar, y asume parte de la culpa cuando el libro no funciona. Tiene una influencia enorme sin autoridad formal. Ese encuadre es mucho más útil.
Los PMs no son la voz del cliente. Esta es más sutil. Los PMs hacen investigación de usuarios. Hablan con clientes. Sintetizan feedback. Pero llamarlos «la voz del cliente» es a la vez incorrecto y contraproducente. Es incorrecto porque el feedback de los clientes no es una sola voz — los clientes quieren cosas contradictorias, priorizan distinto y te dicen lo que quieren en lugar de lo que necesitan. Sintetizar eso en una señal útil requiere juicio, no solo recolección. Y es contraproducente porque le permite al resto de la organización abdicar de su responsabilidad de entender a los usuarios. Cuando solo el PM habla con clientes, obtienes productos filtrados por un PM en lugar de productos que realmente funcionan.
Los PMs no construyen nada. Otra más. El romanticismo alrededor de PM suele incluir la idea de que los PMs son creativos en el sentido en que lo son los diseñadores o los ingenieros. Esto es cierto solo en un sentido muy limitado y específico. Los PMs toman decisiones sobre qué construir, que es un acto creativo de un tipo particular. Pero no diseñan la interfaz, no escriben el código, no corren el query. El output principal del PM no es una cosa. Es una decisión, una dirección, una alineación sostenida que les permite a otras personas construir cosas sin renegociar primero los principios básicos cada vez. Si necesitas hacer algo con tus manos — o con tu visión creativa directa — PM te va a frustrar.
PM no es una descripción de puesto estable. Hay algo que quiero decir sin rodeos: lo que hace un PM varía enormemente según la etapa de la empresa, el tipo de empresa, la composición del equipo y el bagaje del PM en cuestión. Un PM en una startup de veinte personas hace algo significativamente distinto de un PM en una empresa de cinco mil, que a su vez es distinto de un PM en una empresa de plataforma con un ecosistema de desarrolladores. Este libro irá señalando esas diferencias, pero conviene que entres sabiendo que «PM» es más una categoría que un puesto. La categoría se define por la responsabilidad sobre los resultados del producto y por el trabajo de convertir problemas ambiguos en decisiones ejecutables. La forma específica de esa responsabilidad y de ese trabajo varía más de lo que la mayoría del contenido sobre PM reconoce.
Sobre la era de la IA, en específico
En este prefacio he sido cuidadoso al describir el efecto de la IA sobre el trabajo de PM sin caer ni en lo apocalíptico ni en lo desdeñoso, porque ambos modos de fallar son comunes y ninguno sirve.
La versión apocalíptica: la IA va a eliminar el product management. Los PMs serán reemplazados por sistemas de IA que hablan con los usuarios, sintetizan feedback, generan specs y operan productos automáticamente. Esto no va a pasar en el corto plazo por una razón concreta: la parte difícil de PM no es procesar información, es el juicio bajo incertidumbre; y el juicio bajo incertidumbre exige rendición de cuentas, y la rendición de cuentas exige una persona. Cuando la estrategia de producto de la IA resulte equivocada — y va a resultar equivocada — alguien tiene que hacerse cargo, explicarla, actualizar a la organización y comprometerse con una nueva dirección. Ese es trabajo humano, y lo seguirá siendo por más tiempo del que la mayoría predice.
La versión desdeñosa: la IA es solo una herramienta, PM es PM, los fundamentos no cambian. También es errónea. La mezcla de habilidades se está moviendo. El trabajo que antes tomaba tiempo y funcionaba como entrenamiento en el puesto se está automatizando más rápido de lo que la mayoría de los practicantes se ha adaptado. Los PMs que prosperen en la próxima década se van a ver distintos — en cómo piensan su palanca, en qué gastan sus horas y en qué consideran su competencia central — de los PMs que prosperaron en 2018.
La versión honesta es: la IA cambió significativamente las condiciones de operación de PM, de maneras que dejan las partes de juicio y convicción más expuestas y más críticas, mientras vuelven las partes de producción y recolección de información más rápidas y baratas. Si te gustaba PM porque te gustaba escribir PRDs, vas a encontrar menos de esa satisfacción disponible. Si te gustaba PM porque te gustaba decidir — decidir de verdad, con información incompleta, contra restricciones reales, y luego vivir con las consecuencias — vas a encontrar más espacio para eso que nunca.
Este libro trata, en parte, de ayudarte a descubrir cuál de las dos cosas te gusta a ti.
Cómo usar este libro
Cada capítulo termina con un ejercicio. Haz los ejercicios. No porque los ejercicios sean útiles por naturaleza — la mayoría de los ejercicios de desarrollo profesional son trabajo de relleno disfrazado de reflexión — sino porque la pregunta que este libro intenta responder (¿de verdad quieres este trabajo?) no se puede responder solo leyendo. Tienes que probar esa forma de pensar, notar cómo se siente, observar si te da energía o te la quita.
Algunos ejercicios están diseñados para hacer aflorar una respuesta real rápido. Están calibrados para que a quienes van a disfrutar el trabajo de PM les resulten interesantes, y a quienes no, les resulten tediosos o arbitrarios. No te voy a decir cuál es cuál, porque eso arruinaría el propósito. Presta atención a tu reacción, no solo a tu respuesta.
Los capítulos no tienen que leerse en orden, pero los escribí para que se construyan unos sobre otros. El primero — qué hacen realmente los PMs — es el cimiento. Todo lo demás asume que lo leíste. Los capítulos posteriores sobre cualidades y patrones de pensamiento son más difíciles de interpretar sin la base del primero.
Por último: este libro está escrito desde mi perspectiva, que es una perspectiva específica. He sido PM en transporte, comercio, educación y publicidad. He trabajado en startups, scale-ups y empresas de tecnología muy grandes. He gestionado productos de hardware, de software y de plataforma. Pero no lo he hecho todo, y mi experiencia ha moldeado mis puntos de vista. Donde ofrezco una afirmación general, intenté anclarla en algo más que la anécdota personal. Donde ofrezco una opinión personal, intenté señalarla como tal.
El trabajo merece entenderse con claridad. No merece ni sobrevenderse ni infravalorarse. Empecemos por lo que realmente es.