Gerente de Producto vs Propietario del Producto

es una pregunta interesante y que lleva tiempo desempaquetar. Veamos de dónde se originaron estos Términos y disciplinas y cómo algunos marcos comunes los explican.,

Cuando comencé mi carrera, me llamaron Analista de negocios. Hice muy poco «análisis de negocios», ya que lo veríamos en las empresas de TI tradicionales. Honestamente, hice muy poco de lo que enseño como Gestión de productos ahora tampoco. Me encargaron reunir los requisitos de ventas, encontrar una solución, diseñarla y luego enviar el documento de especificación al desarrollo para construirlo.

fui llamado Analista de negocios mientras trabajaba en bancos y otras compañías de servicios financieros. No me llamaron Gerente de producto hasta que salí de eso y aterricé en una startup., Era todo el mismo trabajo que había estado haciendo antes, pero ahora tenía un nombre diferente. Me gustó este nombre. «Gerente de producto» parecía tener seriedad, y cuando miré a otras compañías de tecnología en el Valle, pude ver una trayectoria profesional clara labrada para mí, mientras que los analistas de negocios eran diferentes en cada empresa.

no había oído hablar del término Product Owner hasta años más tarde. La primera vez que escuché el término, le pregunté a alguien qué significaba. Me dijeron que era lo mismo que un gerente de producto, pero era un término usado en Scrum., Habíamos estado usando Scrum durante años, pero todavía me llamaban Gerente de producto, por lo que el hecho de que fueran intercambiables tenía sentido para mí. Rara vez pensé en ello después de eso.

eso fue hasta que tuve mi primera experiencia enseñando gestión de productos en una empresa utilizando el marco SAFe. Estaba haciendo un taller para un banco muy grande cuando uno de los asistentes intervino.

«nos estás enseñando a hablar con los usuarios, pero yo soy propietario de un producto. El Gerente de Producto habla con todos los usuarios y nos dice cuáles son los requisitos., Paso todo mi tiempo escribiendo historias de usuarios y trabajando con el equipo para ejecutar la solución. Estoy confundido.»

Aquí es cuando empecé a indagar en las diferencias entre estos dos roles y cómo las diferentes filosofías les enseñan. Con el fin de entender cómo llegamos aquí

La gestión de productos se remonta a 1931. Hewlett Packard fue una de las primeras empresas tecnológicas en implementar este trabajo y organizarse por productos en la década de 1940., La mayoría de las empresas de Silicon Valley han tenido gerentes de producto desde el principio, y muchos de mis amigos que han trabajado allí en los años 80 y 90 eran, de hecho, gerentes de Producto. Por lo tanto, esta disciplina no es nueva, pero está evolucionando rápidamente a medida que más empresas comienzan a cambiar a organizaciones de software y comienzan a estructurarse en torno a productos.

Scrum entró en escena justo antes de que se escribiera el Manifiesto Agile en 2001. Introdujo el concepto de propietario de un producto. Esta era una persona que era un proxy para el cliente y le diría a los desarrolladores los requisitos para lo que necesitaba ser construido., En los primeros días, cuando muchos de los creadores de estos procesos estaban trabajando como consultores en las empresas, el propietario del producto era el cliente, una persona interna en el negocio que se sentaba con el equipo y priorizaba el trabajo atrasado. De hecho, los objetivos de aprendizaje de 2017 para su certificación Certified Scrum Product Owner de Scrum Alliance establecen: «enseñan que el rol del propietario del producto es típicamente desempeñado por el cliente, o representante del cliente, como un gerente de producto.,»

cuando se observa el rol del propietario del producto en la mayoría de la literatura de Scrum, sus tres responsabilidades principales incluyen las siguientes:

• Definir el backlog del producto y crear historias de usuario procesables para los equipos de desarrollo. (Quién crea las historias de usuario varía dependiendo del entrenamiento Scrum)
• prepara y prioriza el trabajo en el backlog.
• acepte las historias de usuario completadas para asegurarse de que el trabajo cumple con los criterios.,

mientras que el currículo cambia entre los profesores y las organizaciones, estas son las cosas en las que se centran principalmente durante los cursos de dos días para certificar a los propietarios de productos. Si bien Scrum tiene mucha información sobre los procesos y rituales de qué hacer como propietario de un producto, deja muchas preguntas que son importantes para crear productos exitosos sin respuesta. Estos se centran principalmente en torno a «¿cómo sabemos que estamos construyendo lo correcto?»

Aquí es donde entra en juego la gestión del producto., A un buen gerente de producto se le enseña cómo priorizar el trabajo contra objetivos claros orientados a los resultados, cómo descubrir y validar el valor real del cliente y del negocio, y qué procesos se necesitan para reducir la incertidumbre de que el producto tendrá éxito en el mercado.

sin esta experiencia en Gestión de productos, alguien puede efectivamente pasar por los movimientos del rol de propietario de producto en Scrum, pero nunca puede tener éxito en asegurarse de que está construyendo lo correcto.,

si te llevas a tu equipo Scrum, si te llevas Scrum como un proceso para tu organización, sigues siendo un gerente de Producto. La gestión de productos y Scrum funcionan bien juntos, pero la gestión de productos no depende de Scrum. Puede y debe existir con cualquier marco o proceso.

recientemente tuve un propietario de producto cuyos desarrolladores se trasladaron a otra parte de la organización que acudió a mí porque estaban preocupados de que no pudieran ser una persona de producto en esta empresa por más tiempo. Toda su identidad aparentemente dependía de tener un equipo de desarrolladores.,

como Gerente de Producto, sus funciones y responsabilidades cambiarán dependiendo de su contexto y la etapa de su producto. Sin un equipo Scrum o con un equipo más pequeño, es posible que esté haciendo más trabajo de estrategia y validación con el descubrimiento de problemas en un producto que aún no se ha definido. Con un equipo Scrum, puede estar más enfocado en la ejecución de soluciones. Como gerente de Gerentes de producto, puede liderar la estrategia para una parte más grande del producto y entrenar a sus equipos para descubrir y ejecutar bien.,

El framework SAFe enseña esto de manera diferente, y creo que es uno de los puntos más débiles en todo el framework. En SAFe, los gerentes de producto son los gerentes de los propietarios de productos y son responsables de las interacciones y el trabajo externos. Hablan con los clientes, definen los requisitos y el alcance de los productos a construir, y lo comunican a los propietarios de los productos. Los propietarios de los productos son internos, definen los componentes de la solución y trabajan con los desarrolladores para enviarla.,

He capacitado a decenas de equipos que son de uso Seguro y nunca he visto que esto funciona bien. Los propietarios de productos están desconectados de sus usuarios e incapaces de crear soluciones efectivas para ellos que realmente resuelvan sus problemas, porque no entienden bien los problemas., Los gerentes de producto son esencialmente waterfalling abajo de los requisitos a ellos y los equipos no se les permite demostrar si estas son las cosas correctas para construir o no. Nadie está haciendo trabajo de validación.

he escuchado muchos argumentos de que los propietarios de productos no tienen tiempo para hacer ambos roles. En el contexto actual, eso es cierto. Los propietarios de productos con los que hablo pasan 40 horas a la semana escribiendo historias de usuarios. En ese punto, tienes que preguntarte, ¿son esas historias de usuario incluso valiosas? ¿Contra qué los están priorizando? ¿Cómo saben que resolverá un problema?,

Si tienes una persona que pasa tanto tiempo escribiendo historias de usuario cada semana, cada semana, estás cayendo en la trampa de construir — concentrándote en la cantidad de artículos que lanzas y no en la calidad.

con un buen marco de estrategia en su lugar y una priorización despiadada en torno a unos pocos objetivos clave, una persona puede hablar efectivamente con los clientes, comprender sus problemas y ayudar a definir las soluciones con el equipo. Incluso el CEO de Scrum.org está de acuerdo en que este puede ser el caso, aunque, al parecer, a regañadientes., Scrum Inc también dice que el propietario del producto debe pasar la mitad de su tiempo hablando con los clientes y la mitad trabajando con el equipo. No estoy 100% a bordo con esta división, pero la dirección es buena. La cantidad de trabajo externo vs interno cambiará dependiendo de la madurez y el éxito de su producto. Nunca deberías hacer todo este trabajo a la vez.,

enseño a mis clientes que los gerentes de producto en puestos senior (VPs o Product Leads o middle managers) se concentran en definir la visión y la estrategia para los equipos basados en la investigación de mercado, una comprensión de los objetivos y la estrategia de la empresa, y mirando el estado actual de éxito de sus productos. Los gerentes de producto sin equipos Scrum o con equipos más pequeños (un diseñador UX y un desarrollador, por ejemplo) ayudan a validar y contribuir a esa estrategia para futuros productos. Una vez que validamos la dirección, creamos equipos Scrum más grandes alrededor de estas personas y creamos soluciones.,

es importante tener esta flexibilidad en el tamaño del equipo también dependiendo de la etapa de su producto. Si le das a un gerente de producto un gran backlog del equipo scrum para que siga llenándose mientras estás en el modo de descubrimiento, mantendrán ese backlog lleno. Pero, también se debatirán entre mantener el trabajo fluyendo hacia los desarrolladores y tratar de hacer el trabajo para validar la dirección. Como resultado, ninguno de los dos se hace bien.

si desea construir productos que creen valor para sus negocios y clientes, necesita una buena base de gestión de productos en su empresa., Si quieres una carrera profesional para tu gente, necesitas darles esta base para que puedan crecer en puestos más altos. Así que recuerde a su gente que todos son gerentes de Producto. Pueden estar desempeñando el papel de propietario de un producto en un equipo de Scrum la mayoría de los días, pero todavía necesitamos que piensen como un gerente de producto y validen que estamos construyendo las cosas correctas.

— —

Melissa Perri es la CEO de Produx Labs, una consultoría que ayuda a las organizaciones a aprender y adoptar buenas prácticas de gestión de productos y Liderazgo de productos., Dirige una escuela en línea para gerentes de producto en Product Institute y para líderes de producto en CPO Accelerator. Es profesora titular en la Harvard Business School.

Esta fue publicado originalmente en melissaperri.com