¿Cómo puede un gerente de producto dar una buena estimación de las características que se implementarán?

No existen cosas como “buenas estimaciones”. Son solo eso: aproximaciones. Siempre hay sorpresas con el software, no solo porque descubrimos cosas nuevas a medida que implementamos el código, sino también porque las cosas cambian en el negocio y el mercado (la mayoría de las veces).

La idea de que se pueden evitar las sorpresas es errónea. Se piensa que el problema es que necesitamos mejores estimaciones. Y eso lleva a pensar que o bien el proceso de estimación necesita mejoras o que necesitamos escribir mejores requisitos. Esto lleva a señalar con el dedo entre la gestión del producto y la ingeniería.

Esta es una distracción que no sirve al negocio, ya que distrae de lo más importante: entregar valor al cliente.

El problema fundamental es que el foco está en lo incorrecto. El enfoque debe estar en qué problemas de los clientes estamos tratando de resolver y cómo podemos probar nuestras suposiciones subyacentes sobre cómo podemos resolver esos problemas lo más rápido posible. Esto significa llevar el producto a los clientes lo más rápido posible (sin sacrificar la calidad, por supuesto), realizar pruebas, obtener comentarios de los usuarios e iterar continuamente desde allí.

Si está ejecutando ágilmente, digamos scrum, entonces está en condiciones de enviar productos a los clientes cada pocas semanas (idealmente 2 semanas), lo que significa que está aprendiendo en cada iteración. En lugar de enfocarse en una gran entrega que seguramente fallará porque constantemente está tratando de equilibrar la combinación de alcance, tiempo y presupuesto para cumplir con una fecha imaginaria, está buscando entregar actualizaciones incrementales continuas, lo que mantiene el enfoque en entregar constantemente valor para el cliente y aprender de los comentarios de los clientes.

Este es un cambio de paradigma en el pensamiento de la forma tradicional en cascada de entregar software.

Odio decírselo a sus ejecutivos, pero solo tendrán que despertar a esta realidad.

Comprometerse con la línea de tiempo es más similar a lo que hacen los gerentes de proyecto que a los gerentes de producto. En un equipo muy pequeño, esto generalmente se combina en una sola persona, por supuesto, pero si ese es el caso, ese compromiso probablemente recaerá en quien sea responsable de la entrega, por ejemplo, el jefe de ingeniería.

Independientemente del tamaño y la composición del equipo, quien sea el propietario del producto debe ser el responsable final de asegurarse de que el equipo siempre trabaje en el elemento más valioso, es decir , que los esfuerzos del producto estén perfectamente alineados con el objetivo comercial y garantizar el éxito del negocio.

Estimar cualquier cosa relacionada con el tiempo no es algo por lo que un PM deba rendir cuentas.