Acabo de escuchar el podcast de Itnig sobre la Quaterly Product Review de Factorial para elegir el roadmap del siguiente quarter. Me han hecho pensar lo siguiente:

  1. Estoy completamente de acuerdo que cuanto menos clara tienes una propuesta, más largo es el documento. Las buenas propuestas tienen documentos cortos, con el problema a solucionar, el impacto que esperamos tener, por qué debemos resolverlo ahora y qué dirección tomaremos

  2. Es totalmente cierto que los equipos que tienen menos claro qué hacer son los que están más nerviosos. Cuanto tienes muy claro el problema que tiene más impacto, y tienes claro cómo vas a atacarlo, es muy fácil de compartir con el resto de la empresa.

  3. ¿Es responsable el Product Director de que sus equipos prioricen y solucionen correctamente? Desde mi punto de vista, es un claro sí. Los equipos deben ser empoderados, autónomos. Pero el Product Director es responsable de todos sus equipos.

Los managers deben entrenar y hacer coaching a sus equipos. Pero si solo se quedan en coaching, no tienen accountability, no tienen una sana presión. La clave como manager será que sepan dar esa autonomía a sus equipos, pero tengan todo bajo control. Delega y controla.

  1. Me ha gustado la metáfora de @bernatfarrero sobre Product Engineers, "si vas a hacer una reforma en tu casa, te aseguras de entender bien los problemas para decidir qué hacer" Lo mismo con las funcionalidades que hacemos. Los ingenieros deben asegurarse de resolver los problemas

Os dejo el enlace https://lnkd.in/dWMJxFZM

·Ver comentarios en LinkedIn

También puede interesarte

40 clics para pagar dos horas de aparcamiento

Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer

La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.

Iterando el prototipo en vivo mientras los usuarios lo prueban

Siempre he hecho tests de usuario para diseñar mejor. Lo que no había vivido antes era poder implementar el feedback en la propia sesión. Lo que antes tardaba semanas, ahora sale en el día.