¿Cómo es un buen Product Owner?

Este es el octavo mandamiento del libro «Agile Product Management». Descárgalo y obtén las claves para crear productos digitales de éxito.

Por definición, el Product Owner es alguien que atesora los valores ágiles, entre los cuales destacan la colaboración y la transparencia. El Product Owner no es el «jefe» de su equipo de desarrollo, sino que es una parte más del equipo, igual que un desarrollador, tester o diseñador.

Muchas organizaciones no están acostumbradas a este tipo de equipo, así que nos gustaría dedicarle un tiempo a explicar los que creemos que son algunos de los valores y features más importantes de este rol.

Habla muchas lenguas

Lógicamente, no nos referimos al sentido literal, sino a que el Product Owner ejerce de punto intermedio entre los equipos técnicos y de negocio, y necesita ser capaz de comunicarse de forma efectiva con todo el mundo.

Hablar con tus clientes, directivos, equipos de ventas, colegas de marketing, los propietarios en la entrada y los desarrolladores en la cuarta planta… todo esto forma parte del día a día del Product Owner. Y sí, ¡es mucho!

Como resultado de esto, un buen Product Owner necesita aprender a compartir información con todos estos equipos de forma efectiva y comprensible. Es inevitable tener que contestar a preguntas técnicas que formule el equipo de negocios, y viceversa.

Un buen Product Owner puede prescindir de la jerga técnica y confusa y responder de forma clara y efectiva.

Expresa los valores de negocio y la misión de la empresa

Como Product Owner, eres el portavoz de una gran parte de tu empresa frente a tu equipo de desarrollo. Tienes que ser capaz de expresar lo que te gustaría que construyesen, pero también el valor que eso representa para que el equipo de desarrollo entienda y se implique con el producto en el que están trabajando.

Es un poco friki

Serlo te ayudará a entender lo que está haciendo tu equipo, además de por qué y cómo; incluso aunque no estés directamente implicado en el desarrollo de tu producto.

Entender qué APIs están utilizando para entregar una feature o las cualidades del framework que están utilizando en el equipo de frontend, son algunos ejemplos de lo que deberías querer aprender (de todos modos, te va a tocar hacerlo en algún momento). Al fin y al cabo, también formas parte del equipo encargado de comunicarle a las partes interesadas qué decisiones técnicas se han tomado y por qué.

Además, un buen Product Owner debería ser independiente y autosuficiente a la hora de afrontar pequeñas tareas técnicas. De esta manera, tu equipo de desarrollo necesitará enviarte la URL de preproducción cada semana, cambiar tu contraseña por quinta vez o cambiar un número de teléfono de la base de datos de pruebas antes de una demostración.

Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy

Está preparado para todo

Un buen Product Owner sabe que trabajar en software puede ser un viaje turbulento. Debe ser una persona con rapidez para pensar en alternativas, reorganizar el backlog si fuese necesario y adaptarse a las circunstancias cambiantes para garantizar que el equipo de desarrollo pueda trabajar en las mejores condiciones posibles.

Un buen Product Owner trabaja con su equipo para superar cualquier obstáculo, y se ganará el respeto del equipo por ser un colega ágil y flexible.

Es un miembro divertido del equipo

El desarrollo de software puede complicarse muchas veces. Mantener una actitud positiva ayuda mucho a que tu equipo se sienta bien, lo que a cambio les hará trabajar mejor juntos. Un poco de humor nunca hace daño cuando nos encontramos ante obstáculos.

Además, asegúrate de darle el crédito correspondiente a tu equipo, no solo en el día a día sino también en momentos importantes, como demostraciones e hitos de producto. A fin de cuentas, son los que lo han desarrollado.

Construye una buena relación con el equipo de desarrollo

Cada persona desempeña un papel dentro del equipo. Es importante que como Product Owner tu papel se perciba de la misma forma que el de tus compañeros del equipo de desarrollo. El Product Owner no debería estar en un pedestal ni ser considerado un miembro especial del equipo. Necesitas demostrarle a tu equipo que eres uno de ellos.

La mejor forma de empezar es jugando con las mismas reglas que tus compañeros. Participa en todos los eventos habituales, ya estéis trabajando con Kanban o Scrum. Tienes que estar disponible para las reuniones diarias, el planning poker, la planificación del sprint, demostraciones y retrospectivas; igual que los desarrolladores, testers y diseñadores.

La reunión diaria

La reunión diaria es el mejor momento para que tu equipo sepa lo que estás haciendo. Escucharte cada mañana les ayudará a entender lo que está por venir en el backlog, pero también les permitirá entender cómo es tu día a día y qué retos afrontas.

Presentación de historias de usuario

Ya sea durante la sesión de planificación del sprint o revisando el backlog, es muy importante que el Product Owner esté presente, ya que este es el momento en el que los equipos suelen cuestionar tus historias de usuario, haciendo que muchas veces evolucionen.

Es también un buen momento para escuchar las conversaciones que mantienen los desarrolladores entre sí, lo que te ayudará a entender qué tipo de features les parecen complicadas y requieren conversaciones más extensas, y cuáles son fáciles de implementar.

Retrospectiva

Jamás se ha visto que un Scrum Master trate de hacer una retrospectiva sin el Product Owner. Ten cuidado, esto sería una mala señal. Ningún equipo ágil y sano querría excluir a alguien de una retrospectiva, y esto incluye al Product Owner.

Siendo tan parte del equipo como cualquier desarrollador, el Product Owner no solo debe estar presente para comentar cualquier problema que pueda existir, sino también para escuchar a los desarrolladores que quieran aportar algo respecto a cómo se está diseñando y construyendo el producto.

Demostraciones

El Product Owner debe asistir a las demostraciones. En algunas ocasiones, el Product Owner será la persona que desarrolle la demostración, pero recuerda que el énfasis debería estar puesto en el equipo de desarrollo: son ellos los que están construyendo el producto y deberían de ser los que presentasen su trabajo y recibiesen felicitaciones por lo que han creado.

Nada estropea más rápido a un equipo que ver a su Product Owner presentar una nueva versión del producto como si fuese fruto únicamente de su trabajo.

Participando activamente en todos los eventos más importantes, el Product Owner es capaz de seguir el día a día del equipo, asegurando que se está construyendo el producto correcto y contribuyendo a la mejora continua del equipo.

Igual que con muchos de los otros grupos de trabajo presentados en este libro, es importante recordar que los rituales diarios de Scrum y Kanban también se enriquecen con variedad de opiniones y perspectivas, así que siempre es buena idea incorporar a miembros del equipo no técnicos en estos momentos importantes

Gestiona a las partes interesadas

Ofrece visibilidad

Parte de tu trabajo como Product Owner es asegurarte de que las partes interesadas en tu producto entienden lo que está sucediendo: ¿qué se está construyendo? ¿Por qué? ¿Qué efectos se espera que tenga? Todas estas son preguntas que escucharás a menudo.

Existen muchas formas de comunicarse con esas partes interesadas y, según sea la cultura y tamaño de tu empresa, diferentes estrategias: desde una wiki bien documentada hasta un boletín semanal.

Otra gran forma de comunicar el trabajo de tu equipo es con una buena gestión visual y mostrando una total transparencia con cualquier parte interesada que quiera saber cómo avanza el desarrollo del producto.

La gestión visual es parte esencial de la vida diaria en Kanban, y hoy en día también vemos a muchos equipos Scrum adoptando este método de gestión.

Esto os permitirá a ti y al equipo de desarrollo, así como a otras partes interesadas, saber con rapidez y claridad cómo está transcurriendo la vida del producto en cualquiera de sus etapas.

Aprende a decir "no"

Como Product Owner, tendrás que lidiar con los desarrolladores. A veces, te dará la sensación de que estás protegiendo a los dueños empresariales y las partes interesadas. También debes proteger tu producto, y para eso hay que aprender a decir «no».

"No, eso no es lo que vamos a hacer después". "No, esa feature no encaja en este lanzamiento, ni en el producto en general". "No, no podemos terminar seis meses antes". Decir todo esto no es nada fácil.

Algunas veces tendrás que defender posturas controvertidas y convencer a las partes interesadas y a los directivos para que acepten cosas que en principio no tenía intención siquiera de escuchar. Es uno de los aspectos más importantes y por lo general, más difíciles de ser Product Owner.

Para saber más: descarga el Product Ownership Starter Toolkit