Cómo evaluar las capacidades de un candidato para ser Product Owner

[Tana]

Hola de nuevo!

Me han preguntado qué capacidades tiene que tener alguien que pueda ser Product Owner, y si existen algunas pruebas o ejercicios que se puedan hacer para evaluarlas.

En resumen:

¿Cuál es el skillset ideal de un Product Owner?

¿Cómo comprobar que alguien lo tiene?

Preguntas fáciles, eh? xD

Por mojarme un poco, diría que el skill set es principalmente:

• Comunicación. Esta es la tarea principal.
• Conocimientos técnicos. Los suficientes para saber cómo funciona la tecnología, cómo se desarrollan productos, cómo codificar.
• Organización y disciplina. Ser comunicativo y asegurarse de que no hay preguntas / historias de usuario sin respuesta.

Saludos y gracias de nuevo,

    Tana.

[Juan Ignacio]

Una característica muy importante (pero que no tengo ni idea de como evaluar) es que tenga atribuida responsabilidad y autoridad REAL sobre el proyecto.

Me explico. He visto --sobre todo en la administración pública-- que a veces se pone a una figura intermedia, un proxy, para entendernos, entre el equipo y el que realmente toma las decisiones. En ese caso, el PO no es el auténtico PO. El síntoma típico es que al tratar con él constantemente salgan las frases "tendré que consultarlo"*, "ahora no te lo puedo decir", que las decisiones tarden muchísimo en tomarse y/o que se estén cambiando constantemente. En este último caso, además, es muy probable que el ente que esté tomando realmente las decisiones sea un comité. Si así fuera, lo único razonable es gritar "¡Huid, Insensatos! y alejarse lo más rápido posible. JMHO.

* Obviamente el PO no tiene que saberlo todo, pero si de cada 10 preguntas 9 son aplazadas ... Your P.O. is not a P.O.

--

---
Has recibido este mensaje porque estás suscrito al grupo "AgileCanarias" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-canaria...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Juan Ignacio Rodríguez de León
Móvil: 605 890514
E-Mail: euri...@gmail.com
http://www.elornitorrincoenmascarado.com/
http://descon2.com/

[Juanma Barroso]

Creo que el skill set sugerido por Tana es ideal, aunque yo tengo una duda - desde hace bastante tiempo - , y es que tengo la sensación de que un Product Owner debe estar alineado con la estrategia del producto, debe entender muy bien el producto y la competencia. En definitiva creo que un product owner no es un rol que se pueda contratar y darle el titulo de PO, tengo la sensación de que debe tener claro la estrategia del producto y  conocer el negocio (competencia, posibles clientes, etc ...).

No sé como lo ven ustedes, yo no lo tengo 100% claro, pero si que es un "feeling" que tengo desde hace tiempo... :)

Saludos !! 

Juan Manuel Barroso

[Juan Ignacio]

+100 a lo de Juanma, no se puede subcontratar al P.O.

[Tana]

Totalmente de acuerdo. El PO debe ser alguien interno. En este caso el "cliente" del producto es la propia empresa. Y el PO es la voz del cliente, que no tiene que ser necesariamente el decisor, sino el que agrega las prioridades y las transforma en cosas accionables.

Gracias por las respuestas!

Alguna idea en cuanto a ejercicios, etc?

Saludos,

   Tana.

[Fran Reyes Perdomo]

A veces depende del contexto, como rule of thumb coincido con algunas cosas:

* Visión y comprensión del dominio 

* Comunicador y colaborador

* Saber resolver conflictos y tomar decisiones

* Saber escuchar y ser flexible

* Capacidad de aprendizaje

* Atlético, guapo, limpio y sin flequillo.

[Tana]

Lo de sin flequillo me lo apunto :D

[Yeray Darias Camacho]

No tengo experiencia aquí, pero me quedo con la respuesta de Fran. Y me desmarco de una de las cosas propuestas. En mi opinión no creo que el PO, si con PO nos referimos a la definición clásica de Scrum, deba saber de codificación o desarrollo del software. 

Creo que debe entender que es un proceso complejo, pero no necesariamente de desarrollo ni de codificación, en cambio sí que ha de tener un profundo conocimiento de la industria a la que va enfocado el producto.

Yeray Darias about.me/yeray_darias

[Juanjo Coello]

Hola!

Habiendo trabajado con buenos POs y malos POs (aunque en realidad eran Product Managers dentro del proceso eran muy similares a los POs de Scrum), desde el punto de vista de desarrollador las mejores características para mi eran:

- Conocimiento del área. Saber explicarnos por qué hacíamos las cosas qué hacíamos, en el orden en que las hacíamos. Si le preguntábamos por qué estábamos haciendo una funcionalidad en particular, nos sabía explicar cuál era el motivo desde el punto de vista de producto, qué estaban haciendo otros competidores, donde nos posicionábamos y qué queríamos conseguir (Que como ingeniero diera la sensación de que había hecho "la tarea")

- Saber escuchar y aceptar sugerencias del equipo. Muchas veces había alternativas más fáciles de llevar a cabo desde el punto de vista de ingeniería, que afectaban al producto final. Saber oírlas y valorarlas daba una sensación de ownership a los desarrolladores que ayudaba a su implicación. 

- Saber defender su criterio y sus decisiones. Normalmente un PO no es la fuente única de la verdad ni el Dios supremo, y se ve influenciado / determinado / mandado por otras personas (su jefe, márketing, ventas...) Saber "defender" su visión de producto de tal forma que el equipo no está dando bandazos de un lado a otro desarrollando cosas distintas ayuda a tener un sentido de propósito. 

- Tener entusiasmo. Que se le iluminen los ojos cuando habla de las funcionalidades que vamos a desarrollar, el impacto en los clientes/usuarios, las posibilidades que se están creando... 

- Saber cómo medir impacto del producto. Saber si las funcionalidades funcionan o no y en qué medida (Reportes, Gráficos, Estadísticas, Encuestas, etc)

- Conocimientos tecnológicos. No es necesario que sepa picar código, pero sí que sepa hablar la "jerga" y sepa entender las limitaciones técnicas detrás de cada decisión que se toma. Siempre estaremos nosotros para limitar su imaginación, pero si a priori saben que algo es muy, muy complicado, aligera el tiempo perdido investigando soluciones. 

Toda mi experiencia se basa en 3 Product Managers distintos, uno muy bueno, otro regulero (Tech Lead y PM a la vez) y uno bastante malo, todos en una misma compañía. Your  mileage may vary.

Salu2! 

[Tana]

Gracias Juanjo, muy interesante tu experiencia! Me ha gustado mucho lo de "que se le iluminen los ojos" y lo de "defender su criterio". Estoy de acuerdo en la importancia de tener un rumbo y motivar al equipo.

Saludos!

[Francisco Mesa]

Hay algo que me gusta de Juanjo Coello: " Saber cómo medir impacto del producto." Creo que resume algo que para mí es fundamental: que conozca cómo hacer las cosas, o el coste/ventaja que tiene el proceso de llevarlas a cabo. Ustedes saben cómo hacer un proceso iterativo de construcción de un artefacto software, pero en ocasiones el responsable o no sabe lo que cuesta llevar a cabo una especificación o las implicaciones que conlleva.

Seguro que se habrán encontrado en más de una ocasión con casos en los que se piden artefactos por parte de personas que no saben de qué están hablando realmente y lo que es peor, no tienen intención de conocerlo.

--------------------------------------------------------------

LinkedIn: http://www.linkedin.com/in/franciscomesa

		Francisco Mesa about.me/franciscomesa

Twitter: @franciscomesa

Skype: francisco_mesa

Mobile: +34 686645701 (Yes... Spain)