Reseño la edición en español, que está a libre disposición en la web de Product School aunque no esté aquí en GoodReads.
Buscaba un libro para entender la figura del PM después de años trabajando con POs y PMs (que en realidad eran POs renombrados o los jefes de los POs) sin que me encajase mucho mi realidad con lo que leía en los artículos o escuchaba en las charlas del mundillo.
Me costó decidirme por qué libro empezar ya que no quería ni teoría pura, ni un listado de obviedades y cosas de sentido común exquisitamente narradas, ni que me vendieran otro marco de trabajo.
No sé si hay libros mejores porque no he leído otros (aún) pero este ha cumplido por completo con mis expectativas particulares y por eso le doy 5 estrellas.
Cubre todo el ciclo de vida del producto (estrategia, descubrimiento, diseño, implementación, lanzamiento y posterior) de manera muy estructurada, y en cada fase explica el papel del PM y como debería ser su interacción con los diferentes actores involucrados. Pero no se limita a un vistazo teórico sino que explica prácticas concretas: personas, hipótesis de oportunidad (que yo conozco como épicas bien redactadas), priorización ICE y RICE, MVP, A/B testing, KPIs, value proposition canvas, Sprints de diseño... evidentemente no al detalle pero si a un nivel usable y con consejos de "famosillos" y referencias para saber cómo ahondar más si lo necesitamos.
Me gusta que no es un libro para complacer a todo el mundo. Está centrado en productos tecnológicos. Te dice que para ser un buen PM deberías tener conocimientos técnicos y te recomienda hacer un bootcamp si no los tienes, de igual manera que te dice que es indispensable ser un buen comunicador. Cuando te habla de los marcos de trabajo de los ingenieros te dice claramente que en Agile como PM tendrás mucho más trabajo que en cascada, y con Kanban más aún.
Por deformación profesional me resulta muy curioso que se hable de Agile, Scrum y Kanban pero no se mencione la figura del Scrum Master, Agile Coach o similar como otro actor con el que interactuar. Pero claro es que el libro al explicarte como ser un buen PM ya te dice lo que el Agile Coach te diría (equipos empoderados, liderazgo servil etc.), incluso comenta que si tus ingenieros son Junior te costará más trabajo (a ti PM) hacer que el marco de trabajo funcione, es decir que tú eres el coach cuando el equipo no sea maduro para funcionar en Agile por si mismo. Realmente este debería ser el camino, y supongo que será la realidad en algunas empresas, de mi lado lo que puedo decir es que ojalá más PMs se leyeran libros como este.