Español

Errores comunes del gerente de producto (y cómo salir de ellos)

Hacia el mes 18, algo silencioso le ocurre a la mayoría de los PMs. La cadencia de lanzamientos está bien. Los standups están bien. La presentación del roadmap recibió un repaso el trimestre pasado. Pero las victorias no se componen como lo hacían en el mes seis. Ventas sigue interrumpiendo con peticiones de cuentas concretas. Ingeniería ha dejado de objetar en el refinamiento, lo cual suena a victoria y no lo es. No puede distinguir si es el rol, la empresa, o usted.

Es identificable por patrones. Vemos esto en cada organización de PM con la que hemos trabajado, y los patrones son casi siempre los mismos siete. Aquí están, con el síntoma que delata cada uno, el número que hace real el costo, y una solución que puede ejecutar esta semana. Léalo una vez. Elija el que le escoció. Haga la solución. Vuelva a leerlo en 30 días.

Error 1: modo fábrica de funcionalidades

Síntoma: Mide el éxito en tickets cerrados. Su dashboard de lanzamientos cuenta funcionalidades enviadas. Sus retros celebran "cumplimos 14 de 15 compromisos este trimestre". Nadie del equipo puede nombrar la métrica que se suponía que la última funcionalidad iba a mover, y nadie pregunta.

Número real: El análisis de Itamar Gilad sobre resultados a nivel de funcionalidad, respaldado por los datos publicados de Microsoft sobre los experimentos de Bing y los estudios de testing de Google, aterriza aproximadamente en el mismo lugar: cerca de un tercio de las funcionalidades enviadas mueven las métricas objetivo de forma positiva, un tercio las mueven de forma negativa, y el resto quedan planas. Traduzca eso a una fábrica de funcionalidades y está enviando con una tasa de aproximadamente 70% sin resultado. Si su equipo envía 30 funcionalidades al año, veinte de ellas no ganan nada o perjudican activamente el producto.

Solución: Elimine el dashboard de lanzamientos. Reemplácelo por un dashboard de resultados, aunque tenga tres filas por ahora. Cada funcionalidad, antes de entrar en la cola de construcción, recibe una predicción de métrica preregistrada por escrito. Formato: "Si enviamos X, esperamos que la métrica Y se mueva de A a B en 30 días. Confianza: media." Si no puede escribir esa frase, la funcionalidad no está lista para construirse. La disciplina no es que la predicción sea correcta; es que la predicción exista siquiera. La calibración viene de comparar lo que escribió con lo que pasó.

Error 2: saltarse el discovery

Síntoma: Cero entrevistas con clientes en su calendario este trimestre. Se dice a sí mismo, y a su mánager, que está "demasiado ocupado ejecutando". Lee tickets de soporte a veces. Vio una demo de ventas el mes pasado. Eso es discovery, ¿verdad?

Número real: El benchmark de discovery continuo de Teresa Torres (el que la mayoría de las organizaciones de PM senior referencian) se sitúa en al menos un punto de contacto con clientes por semana, hecho personalmente por el PM. La mayoría de los PMs que se sienten estancados corren a 0-2 puntos de contacto por trimestre. Esa es una brecha de 12x a 50x entre lo sano y lo estancado.

Solución: Antes de seguir leyendo este artículo, abra su calendario y reserve tres entrevistas con clientes de 30 minutos para esta semana. Recluta a través de los tickets de soporte y la analítica de producto, no a través de traspasos de ventas. (Las entrevistas presentadas por ventas se sesgan hacia prospectos enterprise que quieren funcionalidades, no patrones.) La primera entrevista se sentirá inútil. La tercera sacará a la luz algo que no sabía el lunes. Si tres se siente pesado, ha encontrado su error.

Error 3: lanzar y olvidar

Síntoma: Las revisiones de lanzamiento existen en el calendario del equipo. Las revisiones post-lanzamiento a 30/60/90 días no. La única vez que alguien mira una funcionalidad después del lanzamiento es cuando se rompe o cuando ventas se queja de que es confusa.

Número real: En las comunidades de PM que hemos encuestado de manera informal, aproximadamente el 80% de los post-mortems de funcionalidades ocurren solo en modo fallo: caída, regresión, bajón de NPS. Las funcionalidades que rinden poco en silencio (enviadas, usadas por el 4% de los usuarios previstos, sin movimiento de métrica) no reciben un post-mortem porque nadie lo notó. Esas son las funcionalidades de las que está más orgulloso en su evaluación anual y que no le hicieron nada a la empresa.

Solución: En el momento del lanzamiento, antes de que la funcionalidad salga en vivo, ponga una invitación de calendario en su propio calendario con fecha a 30 días vista. Dueño: usted. Asistentes: usted y un ingeniero. Agenda: descartar, iterar, o escalar. Escriba la decisión en un párrafo y publíquela donde el resto del equipo pueda verla. Si la respuesta es descartar, descártela de forma visible. Los PMs que descartan funcionalidades públicamente se ganan más confianza que los PMs que nunca tienen un fracaso que reportar, porque el segundo grupo o está mintiendo o no está midiendo.

Error 4: teatro de gestión de partes interesadas

Síntoma: Está en más de 12 horas de reuniones de alineación a la semana. Las decisiones tomadas en las reuniones no se sostienen. El mismo tema vuelve a la semana siguiente. Sale de cada reunión con elementos de acción y ninguna decisión. Está agotado y su roadmap no se ha movido.

Número real: La encuesta de PM de 2024 de ProductPlan situó al PM promedio en 23 horas a la semana en reuniones; el cuartil superior (según el impacto autorreportado y la velocidad de promoción) se sentaba en 14. Esa es una diferencia de nueve horas a la semana, cada semana, entre estar ocupado y ser efectivo. Anualizado, eso son 450 horas, aproximadamente 11 semanas laborales de tiempo recuperado.

Solución: Elija la sincronización recurrente con partes interesadas que tenga la menor densidad de decisiones y cancélela durante dos semanas. Reemplácela por una actualización escrita del viernes con tres secciones, media página máximo: qué se envió, qué está bloqueado, qué necesito para el próximo viernes. Publíquela donde las partes interesadas puedan comentar de forma async. Tras dos semanas, cuente cuántas partes interesadas le reclamaron por la reunión cancelada. El número es casi siempre cero. Los que sí le reclamaron tienen una necesidad real; construya una cadencia más pequeña y específica solo con ellos.

Error 5: especificar de más mientras valida de menos

Síntoma: Sus PRD tienen 12 páginas. Pasó dos días en el último. Ingeniería lee la primera página y hojea el resto. Cero prototipos se han puesto delante de un cliente en el último mes.

Número real: Escribir una sección minuciosa de PRD que nadie lee cuesta aproximadamente tres horas de tiempo concentrado de PM. Construir un navegable de Figma que obtenga reacciones reales de tres clientes cuesta aproximadamente 30 minutos si puede usar componentes existentes, una hora si no puede. El navegable produce señal; la sección del PRD produce un rastro documental.

Solución: Limite sus PRD a dos páginas. Secciones permitidas: planteamiento del problema, resultado objetivo (con la predicción de métrica del Error 1), solución propuesta en tres viñetas, qué explícitamente NO vamos a hacer, preguntas abiertas. Cualquier cosa que quisiera escribir más allá de la página dos es una señal de que está evitando una conversación con un cliente. Construya el prototipo en su lugar, y deje que el prototipo responda las preguntas sobre las que iba a escribir párrafos.

Error 6: decir que sí a cada petición de ventas

Síntoma: Su roadmap se lee como una lista de cuentas concretas. Cada dos tickets tiene un trato adjunto. La frase "esto está comprometido con Acme" aparece en tres de sus últimas cinco reuniones de planificación. No ha construido nada para sus clientes existentes en dos meses porque el pipeline de tratos se comió el trimestre.

Número real: Los estudios de Intercom, Pendo, y varias organizaciones de producto respaldadas por VC aterrizan en un rango consistente: las funcionalidades construidas específicamente para peticiones de cuentas impulsadas por ventas convierten en ingresos de expansión a una tasa de aproximadamente 8-15%. La misma capacidad de ingeniería, redirigida a funcionalidades de retención o activación para la base existente, convierte a un 30-40% en impacto de NRR. Está cambiando un retorno de 3x por un retorno de 1x porque el 1x es más ruidoso en la sala.

Solución: Construya un formulario de admisión por escrito. Campos requeridos: qué trato, qué ARR, cuál es la alternativa si decimos que no, qué evidencia existe de que otros clientes quieren esto, cómo mediremos el éxito tras construirlo. Haga que ventas lo rellene. Alrededor del 80% de las peticiones "urgentes" mueren en el formulario, porque la alternativa siempre fue "lo apañaremos" y la evidencia siempre fue "este único prospecto lo mencionó". Las que sobreviven al formulario son reales, y las construirá con el contexto adecuado.

Error 7: RICE sin confianza honesta

Síntoma: Abrió su hoja de cálculo de RICE el trimestre pasado. Cada iniciativa se puntuó con un 80% de confianza o más. Algunas con un 90%. Ninguna por debajo del 70%. El resultado de su priorización parecía riguroso y produjo el mismo ranking que su intuición habría producido.

Número real: Los PMs calibrados (el pequeño subconjunto que rastrea su propia precisión de predicción a lo largo del tiempo, como hacen los superpronosticadores de Philip Tetlock) aterrizan en aproximadamente 55-65% en las llamadas de confianza sobre resultados de funcionalidades. Ese es el rango realista para alguien con fuertes instintos de producto y medición honesta. Cualquiera que puntúe por encima del 80% en cada elemento de su backlog se está anclando a un ranking deseado, no estimando. El marco se convierte en teatro.

Solución: Empiece un diario de predicciones. En el momento de puntuar con RICE, anote su número de confianza Y una predicción de una línea de lo que pasará si la funcionalidad se envía. En el momento del resultado (use la revisión a 30 días del Error 3), puntúese a sí mismo: ¿la predicción fue correcta, parcialmente correcta, o incorrecta? Recalibre trimestralmente. Tras dos trimestres de llevar el diario, su confianza promedio derivará a la baja hacia el 60% y su priorización empezará a producir rankings que le sorprendan. Eso es el marco funcionando de verdad.

El meta-error

Lea esos siete de nuevo. Comparten una raíz: optimizar la actividad visible por encima del aprendizaje invisible. Los tickets cerrados son visibles. El reconocimiento de patrones de clientes es invisible. Las páginas de PRD son visibles. Una funcionalidad descartada es visible (incómodamente), una funcionalidad que rinde poco en silencio es invisible. Las recompensas dentro de una empresa tienden a fluir hacia el lado visible de esa línea, que es por lo que los PMs derivan hacia comportamientos de fábrica de funcionalidades y de teatro con partes interesadas incluso cuando saben que no deberían.

La solución no es un marco nuevo encima de los siete. Es una revisión semanal de 30 minutos en la que se hace una pregunta y escribe la respuesta: "¿Qué aprendí sobre nuestros clientes, nuestro producto, o nuestro equipo que no sabía el lunes pasado?" Si la respuesta es nada, ese es el diagnóstico. Los siete errores son rutas distintas al mismo destino, y la meta-solución es un recibo semanal de que fue a algún lugar nuevo.

Qué hacer esta semana

Elija el error que más le escoció mientras leía. Probablemente el que rebatió mentalmente. Ejecute la solución específica:

  • Fábrica de funcionalidades → Escriba una predicción de métrica para la próxima funcionalidad de su cola, antes de que se construya.
  • Saltarse el discovery → Tres entrevistas con clientes reservadas esta semana.
  • Lanzar y olvidar → Una revisión a 30 días en su calendario para el lanzamiento más reciente.
  • Teatro con partes interesadas → Cancele la reunión recurrente de menor densidad de decisiones, reemplácela por una actualización escrita del viernes.
  • Especificar de más → Limite su próximo PRD a dos páginas.
  • Sí a cada petición de ventas → Envíe el formulario de admisión a su contraparte de ventas antes del final de la semana.
  • RICE sin confianza → Empiece el diario de predicciones en la próxima sesión de priorización.

Vuelva a leer esta lista en 30 días. Los errores no desaparecen; rotan. Los PMs que siguen ascendiendo son los que nombran el error actual más rápido cada vez.

Más información