El rol del product manager ha ganado popularidad en la industria tech en los últimos años. A medida que más empresas agregan PMs a sus organigramas, todavía hay mucha experimentación con configuraciones de equipos para encontrar la mejor alineación posible entre producto e engineering. Estas dos funciones trabajan ahora tan cerca como nunca, y aunque se dice que es la receta para equipos de alto rendimiento, muchas empresas todavía luchan por alcanzar buenos niveles de colaboración.
Las estrategias para hacerlo funcionar están bien cubiertas en el sitio web de Martin Fowler. En este artículo me enfocaré más en la perspectiva del ingeniero y cuáles son nuestras expectativas para un buen product manager.
Qué No Esperar#
Como ingeniero yo mismo, he observado fricción viniendo de ambos lados, pero también algunas asociaciones productivas. Aunque se puede argumentar que el equipo o la organización pueden influir en el resultado, depende principalmente de cuánto cada función está dispuesta a colaborar con la otra.
Hagamos un ejercicio y pensemos en estas expectativas al revés. Creo que el rol de PM todavía está en sus primeros días, y por eso asume diferentes formas, especialmente en empresas menos maduras que están comenzando a construir sus estrategias de desarrollo de producto.
Excel Manager#
Un as con macros y maestro en reportar progreso en el steering semanal. Todo el proyecto parece una pieza de arte geométrica con barras apiladas una sobre otra. El excel manager se preocupa muy poco por el ciclo de vida del producto y gastará todas sus fichas en hacer que los devs se comprometan con esos plazos.
Featurista#
Especialista top en investigación de mercado 360. Ella sabe todo sobre Steve Jobs y la historia del iPod, se preocupa por el ciclo de vida del producto, pero no puede permitirse perder tiempo construyendo estrategias porque “Los detalles importan, vale la pena esperar para hacerlo bien”.
Programador Retirado#
Descontento con la idea de ser code monkey para siempre, ella abandonó engineering en busca de felicidad y éxito. Mirando con arrepentimiento la vida que dejó atrás, el programador retirado es un buen aliado y está dispuesto a manejar las expectativas del liderazgo.
La Mano del Rey#
¿Por qué compartir las ideas de uno cuando todos estamos aquí para servir un propósito mayor? Como un filtro pasa-todo, la mano del rey no se arriesga a que dedos apunten en su dirección. Ella es solo la mensajera.
La Idea Central del Product Management#
Lo que los estereotipos anteriores tienen en común (intencionalmente) es que todos delegan las decisiones de negocio a la capa de liderazgo, lo que creo que es el mayor game changer sobre el rol de product manager. Más que diseño o implementación, el PM es responsable de todo el ciclo de vida del producto, desde la idea hasta la implementación, feedback del cliente y rendimiento en el mercado.
Los equipos más exitosos en los que he trabajado son aquellos donde el PM está presente, a veces incluso bajo la misma línea de liderazgo/reporting. PM & EM: Rules of engagement establece 3 reglas fundamentales: Confianza, responsabilidad conjunta y ownership separado.
Incorporar al Equipo en el Negocio#
Una de las cosas que siempre me ha molestado es lo poco que los ingenieros saben sobre los productos que están construyendo. Sorpresa o no, es posible trabajar toda una vida sin saber quién usa el software que estás construyendo y cuánto dinero genera. Discusiones recurrentes con el equipo sobre el rendimiento del producto son una forma poderosa de fomentar la innovación y mantener los niveles de motivación altos.
Un Roadmap para Gobernarlos a Todos#
Construir un roadmap técnico mientras trabajaba en un equipo de producto fue una de las experiencias más contraproducentes que he tenido. Aunque es importante hacer seguimiento de la deuda técnica que necesita ser pagada, si no hay buy-in del producto, la experiencia me dice que esas tareas nunca van a ser implementadas.
Un buen PM es capaz de entender el costo de no pagar la deuda técnica y la incluirá como parte de la estrategia de producto.
Fechas Objetivo, No Plazos#
Si quieres estresar a un ingeniero, pídele un ETA o que se comprometa con un plazo fijado por el liderazgo. Construir software bajo presión solo causa daño al negocio en el sentido de que forzará a las personas a cometer más errores.
Aunque tampoco es aceptable que los ingenieros sean libres de desperdiciar grandes cantidades de tiempo, el PM debería ser lo suficientemente flexible para permitir que la fecha objetivo se mueva o que el alcance sea reducido.
Observaciones Finales#
Cómo debería ser el PM perfecto sigue siendo una pregunta abierta, pero está claro que si tanto producto como engineering trabajan para construir una asociación efectiva, los resultados pueden ser mucho más productivos. Desde el punto de vista de un ingeniero, el PM ideal no es un stakeholder sino un par, muy parecido al CEO de una pequeña startup dentro de la empresa más grande.
