El test PMPO: diferencia entre Product Managers y Product Owners
Un modelo mental para diferenciar entre ambas posiciones y evitar contratrar, y ser contratado, para ejercer unas tareas que no corresponden a lo que se espera.
Esta semana he estado pensando de nuevo en las diferencias entre Product Manager y Product Owners. Los lectores habituales sabréis que mi postura al respecto es que los Product Managers no deberían dedicar una gran parte de su tiempo a escribir historias de usuario, sino que su principal valor es encontrar problemas que valga la pena solucionar para los usuarios y el negocio.
En mi escenario ideal, es el equipo de ingeniería, generalmente el Engineering Manager o el Tech Lead quienes lideran la parte de ejecución, que es donde en principio los Product Owners ponen la mayor parte de su tiempo. Esto es así, porque Product Ownership es un rol, el cual puede cubrir una persona específica, o bien ser asumido por un miembro del equipo.
Ahora bien, para los que estamos lejos de EEUU y Silicon Valley, el rol de Product Owner se popularizó antes que el de Product Manager. Mucho de esto tiene que ver con SCRUM, el framework que creó el rol, y que se adoptó masivamente como una forma industrializada de adoptar el agilismo.
Y claro, nos hemos hecho un lío. Así cuando hablamos de producto, no sabemos si estamos hablando de Product Managers o Product Owners. Algunas empresas utilizan los títulos de forma equivalente. Muchas otras han cambiado los títulos directamente, y lo que antes eran POs ahora son PMs sin haber cambiado realmente su enfoque o responsabilidades.
Al hilo de todo esto esta semana vi este tweet de Gergely Orosz en el que analizaba qué rol era responsable de cada una de las etapas durante el proceso de desarrollo de producto:
El tweet me dio la idea de hacer una visualización similar respecto de las fases y tareas desde el punto de vista de Product Management y Product Ownership. El resultado de un primer borrador rápido, en el que no están todas las que son pero sobre el que probablemente iteraré, ha sido este:
Una vez habiendo definido las distintas fases y actividades o responsabilidades, pensé en visualizar mi modelo mental sobre dónde se enfoca cada uno de los roles. El resultado fue el siguiente:
¿A qué dedica su tiempo un Product Manager?
Como veis las principales diferencias son las implicaciones de tiempo en las fases iniciales y finales del desarrollo. Un Product Manager generalmente dedica la mayor parte de su tiempo en una fase que he llamado estratégica, donde se definen los objetivos de negocio del producto, y se trabaja sobre los inputs tratando de encontrar aquellas iniciativas que puedan mover las métricas. Esta fase corresponde con el espacio del problema u oportunidad y un PM debería pasar el 50% de su tiempo aquí.
Después se pasaría a una fase de planificación dónde trabajando mano a mano con el trío de producto (Engineering Manager/Tech Lead y Product Designer) se trata de buscar soluciones a los problemas, se validan, se estiman y se priorizan terminando todo ello en un roadmap. Aquí la implicación del PM es alta también, pero menor que en la primera fase, pues gran parte de su trabajo consiste en delegar la responsabilidad de encontrar la solución al equipo. Siguiendo el patrón anterior, un buen PM quizás pase el 40% de su tiempo en esta fase.
Por último tenemos la fase de ejecución, en la que básicamente el equipo de ingeniería implementa las soluciones definidas en la fase anterior. Este es el terreno de la gestión del backlog y los rituales del día a día de producto (dailies, refinamientos, demos, retros…). Un Product Manager, para ser realmente efectivo y aportar su verdadero valor en la primera fase, debería pasar el menor tiempo posible aquí. La ejecución, siempre bajo mi modelo mental, es responsabilidad de ingeniería. Para cerrar los porcentajes, diremos que el máximo tiempo que debería dedicar es un 10%.
¿A qué dedica su tiempo un Product Owner?
Como veis en el gráfico, la curva del Product Owner es la opuesta a la de un PM. Una buena heurística para saber si realmente estás actuando más cómo Product Manager o como Product Owner es comprobar de dónde te vienen las iniciativas. Los Product Owners generalmente no están involucrados en la parte estratégica. Hay alguien en el otro lado que decide qué se debería hacer. Su función pasa más por recopilar iniciativas de otros stakeholders que son los que están realmente en contacto con el mercado y los clientes.
En la parte de planificación, los Product Owners sí hacen funciones similares a las de los Product Managers. Si bien dedican menos tiempo a priorizar a alto nivel porque esta venga ya dada por la estrategia definida en la fase anterior, sí que se tienen que apoyar en el trío de producto para encontrar las mejores soluciones, estimarlas y preparar los artefactos para que el equipo de desarrollo pueda ejecutarlas en la siguiente fase.
Es en la última fase, la de ejecución, dónde los Product Owners pasan la mayor parte de su tiempo. Es la fase en la que se escriben las historias de usuario y se define y prioriza y gestiona el backlog. La fase en la que se organizan los sprints y se decide qué hacer en cada uno de ellos, al tiempo que se gestiona la ejecución preocupándose por la calidad de la entrega final. Un Product Owner pasa el 50% de su tiempo dedicado a estas tareas.
Conclusiones
Hemos visto un posible modelo para entender las diferencias entre los roles de Product Management y Product Ownership. No es malo estar en ninguna de las dos posiciones, tanto Product Managers como los Product Owners pueden tener su encaje según el contexto.
Lo que sí es terrible es contratar a Product Managers para hacer el trabajo de Product Owners, y viceversa. Y esto pasa más de lo que debería porque como industria creo que no tenemos del todo claro qué es lo que buscamos cuando ofertamos una plaza de Product Manager o Product Owner. Sinceramente tengo la impresión de que hoy en día ser Product Manager se ha convertido en algo sexy, y las empresas han cambiado títulos para atraer más candidatos a sus ofertas pensando que son puestos intercambiables. No lo son.
De hecho esta forma de visualizar las distintas actividades puede ser útil a la hora de lanzar una oferta, pero también a la hora de pasar un proceso de selección. Una buena pregunta sería pedir al entrevistador que dibujará la curva sobre dónde debería pasar su tiempo el candidato. Si la curva tiende a la parte de ejecución, sabremos que están buscando un perfil de Product Owner. Si se centra en la parte estratégica, un Product Manager.
Y si por casualidad no dibujan una curva si no una recta en la que el candidato dedique su tiempo al 100% en cada una de las fases, piénsatelo. Por una parte esa empresa no tiene mucha idea de lo que necesitan, lo cual siempre es mala señal, y por otra, es imposible estar en todas las fases a la vez siendo efectivo.
🙌 ¡Comparte!
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes utilizar estos enlaces para compartirlo directamente en Twitter o LinkedIn y así contribuirás a que esta lista llegue a más gente.
Muchísimas gracias de antemano, Simón.
Hola Simón,
gracias por este post, que ayuda a estructurar la conversación. Me gustaría hacer unas matizaciones desde mi punto de vista (más centrado en Scrum).
Todos los modelos son válidos cuando funcionan y dan valor. En este caso las discusiones son más de preferencias y relaciones entre roles.
La filosofía de Scrum se basa entre otros en:
1. Desescalar la organización en equipos (o equipos de equipos) más pequeños responsables de entregar valor a cliente, cubriendo todo el ciclo de vida de estrategia > planificación > ejecución > feedback.
2. En estos equipos hay pocas "etiquetas" de roles y mucho solapamiento de funciones entre miembros. Esto facilita la colaboración, la toma de decisiones basada en la inteligencia colectiva y mitiga los riesgos de dependencias.
3. Orientar el ciclo de vida a la entrega de valor, rehuyendo de la secuencialidad y acercándose al feedback lo más frecuente posible.
Así, en un modelo alineado con Scrum se hablará menos de departamentos y fases, conceptos que aparecen en estos gráficos que planteas.
Se suele asignar el "San Benito" de industrializado y masivo a Scrum, con resultados a menudo muy mejorables, aunque retaría a cualquier otro modelo a conseguir llevar la agilidad a entornos tan "hostiles" para ver si le salía mejor. :-)
La separación entre PM y PO que planteas tiene sentido para segregar responsabilidades en equipos medios y grandes, pero como explicaba antes, no es una visión genuina de Scrum. En este caso es mejor no llamar PO a lo que es un "PO proxy", o intermediario del equipo con el PM.
Es difícil llegar a un acuerdo en este debate porque se basa en puntos de vista lícitos y diferentes. En los orígenes de Scrum, el rol se llamaba Agile Product Manager, pero Ken Schwaber decidió cambiarle el nombre a PO tras el desastre del proyecto Centinel del FBI, donde un PM poco empoderado era un "coladero" de los stakeholders en frente del equipo. El nombre de PO quería dejar claro el "ownership" del producto y que por tanto las decisiones importantes pasaban por esta figura.
Te invito a leer un post sobre el tema que escribí el año pasado. https://itnove.com/blog/scrum/product-owner/product-owner-y-product-manager-son-iguales-o-diferentes/
En que consiste esta parte estratégica? Me cuesta imaginar ejemplos de trabajo del pm, hacen balances de presupuestos según los protectos?