Más producto, menos gerentes de producto

Rol de los gerentes de producto vs. otros roles

• Confusión continua entre la gestión de “producto” y la de “proyecto”; muchas organizaciones las mezclan.
• Algunos ven al PM como “gestión de proyectos con pasos extra” (mercado, cliente, estrategia).
• Otros trazan una separación clara: el PM se encarga del por qué/qué, el gerente de proyectos del cuándo, y la ingeniería del cómo/quién.
• En la práctica, muchos PM acaban forzados a hacer coordinación de proyectos y administración de Jira.

Qué hacen los buenos PMs (según el hilo)

• Actúan como “mini-CEOs”: entienden a los clientes, el mercado y los objetivos de negocio; dan forma a la visión y la estrategia.
• Pasan mucho tiempo con usuarios, ventas y soporte; sintetizan el feedback en problemas y prioridades claras.
• Hacen de puente entre las partes interesadas y los ingenieros, aportando contexto, gestionando concesiones y protegiendo el foco.
• Tienen suficiente conocimiento técnico/de arquitectura para entender restricciones y secuenciar el trabajo con inteligencia.

Críticas habituales a los PMs

• Muchos PM son vistos como quienes pasan tickets, crean reuniones o hacen “trabajos de mierda” con poca propiedad real.
• Las organizaciones de CPO que construyen imperios llevan a que los PM posean porciones diminutas (una sola página, el CTR de un botón) lejos de la estrategia.
• Los PM a menudo microgestionan el “cómo” sin entender la complejidad técnica, o evitan por completo a los usuarios.
• Los ingenieros reportan política impulsada por PM, teatro de estatus y presión de plazos sin una dirección clara de producto.

¿Ingenieros como responsables de producto?

• Algunos sostienen que los mejores equipos no tenían PM: los ingenieros, junto con las partes interesadas del negocio, hablaban directamente con los clientes.
• Contraargumento: la mayoría de los ingenieros son malos en gestión de producto y de proyectos sin incentivos ni tiempo; el trabajo de PM aún debe hacerlo alguien.
• Patrones de ejemplo sin PM: objetivos poco claros, investigación de usuarios débil, “campamentos” internos, funciones sobreingenierizadas pero desalineadas.

Ratios, escala y diseño organizacional

• Hay consenso en que “más PM ≠ mejor”; los ratios deben minimizar la interferencia y maximizar la autonomía.
• Los PM aportan más valor cuando son dueños de una superficie importante (todo el producto o un módulo principal), no de pantallas individuales.
• En startups, muchos sienten que los fundadores deberían hacer de PM hasta que realmente no puedan; demasiados PM demasiado pronto se convierten en burocracia.

Técnico vs. no técnico / experiencia en el dominio

• Muchos prefieren PM con al menos algo de programación o comprensión de sistemas, especialmente para productos técnicos o dominios regulados.
• Otros dan más importancia a la experiencia en el dominio y del usuario (finanzas, RR. HH., medicina, comercio minorista) que a la tecnología profunda.
• Los mejores PM, según se informa, combinan empatía por el usuario, sentido de negocio y suficiente intuición técnica para discutir concesiones.

Incentivos, política y cultura

• Las estructuras de incentivos a menudo recompensan la producción técnica sobre el impacto en el usuario, desalentando a los ingenieros de hacer trabajo similar al de PM.
• El comportamiento de los PM está moldeado por los incentivos organizacionales: si el ascenso está ligado a presentaciones y grandes reuniones, eso es lo que obtienes.
• Varios señalan que el mal funcionamiento atribuido a los PM es con frecuencia un problema de liderazgo y cultura, no inherente al rol.

Subhilos varios

• Digresión breve pero acalorada sobre imágenes “hero” de IA/bolsa y su aspecto genérico y de baja calidad.
• Reflexiones más amplias sobre “demasiados roles” en las grandes tecnológicas (PM, scrum master, QA, etc.) y el atractivo de equipos más ligeros y planos.