La primera línea que define el rol de Product Owner en la guía de Scrum dice:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
Esta frase siempre me hizo pensar que, un buen Product Owner debe ser capaz de organizar el trabajo y por tanto debe organizarse a sí mismo de forma efectiva. En mi experiencia, he visto que las personas con mejores dotes de organización personal, tenían mejores capacidades para hacer este trabajo: son transparentes, visualizan fácilmente el trabajo y saben organizar sus actividades en el tiempo. ¿Pero esto cómo se hace? Os copio la siguiente frase de la guía:
How this is done may vary widely across organizations, Scrum Teams, and individuals.
Pues de diversas maneras, probablemente no todas documentadas, sin embargo quiero compartir aspectos que me parecen fundamentales para hacer bien este trabajo. Para algunos detalles insignificantes, para otros los que marcan la diferencia entre un profesional y otro.
Organización de su agenda
Si algo he mencionado en todos los artículos anteriores es la importancia de las relaciones de este rol con el resto de los que hay alrededor de Producto. Todos hacemos producto, sólo que a través de diferentes herramientas y conocimientos. Todos intentamos aportar valor al cliente. Esto requiere de muchas interacciones y por tanto reuniones. El Product Owner está constantemente conversando con personas, manejando documentos, y de cara a su agenda hay 5 aspectos que me parecen clave:
1. Agenda pública
Esto significa que alguien puede acceder a tu calendario y ver los títulos y detalles de tus reuniones. Por defecto los eventos deberían ser públicos y en caso de que algo sea privado sólo esos ocultan sus detalles. El valor está en que alguien puede querer hablar contigo de algo y si ya hay una reunión al respecto quizá te pida asistir pero no crear otra. Esto es un ejemplo de transparencia. La agenda pública puede permitir que te pongan una reunión y te reserven la misma sala para que ni salgas de ahí en todo el día – conozco a pocas personas que se fijen en esto pero es de gran valor porque reduces el tiempo en desplazarte de un lado a otro de la oficina y las probabilidades de llegar tarde.
2. Agenda con detalles
Todos los eventos que crees deben ir detallados. Las reuniones deben tener un propósito, deben llevarse a cabo por que es mas efectivo que el uso de un email o chat, deben tener un problema que resolver así como incluir a las personas estrictamente necesarias – para informar podemos hacer uso de otros medios. En verdad, creo que el Product Owner puede hacer una gran labor de cambio cultural levando a cabo reuniones efectivas. Por ejemplo, cuando convoca a las personas a las reuniones, explicando lo que espera de ellas y para qué las necesita. Muchas veces también le puede tocar decir a otros por qué no están invitados, siempre con educación y criterio Mi último apunte en cuanto a los detalles de las agendas es que, se mencione el artefacto/documento sobre el que se va a trabajar, permitiendo a los asistentes a ponerse en contexto y colaborar. Hacer uso de los artefactos del producto en tus reuniones, garantiza que éstos estén actualizados y además das visibilidad constante de su existencia, uso y contenido a toda la empresa.
3. Reuniones de ciclo de producto
Me gusta el uso del término ciclo de producto porque creo que da cabida a cada ciclo que la empresa haya definido. Con esto no me refiero sólo a los eventos de Scrum que son una parte del ciclo de producto, sino que me refiero a todos los existentes: eventos para revisar los datos del impacto de los incrementos de producto entregados recientemente, eventos para definir tests sobre el producto, elaborar hipótesis, definir la misión del siguiente trimestre… los eventos que sean, deben estar también en el calendario. Considero que el Product Owner debe convertir estos eventos en un hábito – y el resto de asistentes – y asegurarse de que toda su labor permite alimentar con información valiosa estas reuniones, como dije antes con los artefactos del producto. Por mi experiencia, algunas de las reuniones del ciclo de producto conviene hacerlas más cortas pero con más frecuencia, esto es algo que el Product Owner puede observar y ajustar en su contexto y con el equipo de trabajo.
4. Asegurarse tiempo para sí mismo
Siempre he visto a los Product Owners invertir mucho tiempo en reuniones, por lo comentado anteriormente, la labor de interaccionar con otros roles con el objetivo de maximizar el valor del trabajo del equipo de desarrollo. Cuando era Product Owner, de todas las reuniones me llevaba deberes para hacer, y necesitaba tener tiempo para mi misma, para sentarme sola y organizar el trabajo. En mi caso, hacía uso de las horas de baja energía de la oficina: 8:00 – 10:00, 16:00 – 18:00, estos horarios los tenía marcados como reuniones en mi agenda, pero el único invitado era yo :). Otro truco que siempre aplicaba era dejarme mínimo 10 y máximo 30 minutos entre reuniones, y así justo al salir de una, ejecutaba lo que podía – enviaba la minuta al menos – y las notas las añadía a mi sistema de organización personal. Gracias a estos detalles, no se me acumulaba tanto el trabajo durante el día. Hay que encontrar el momento de sentarnos a hacer.
5. Rechazar reuniones
Rechazar reuniones sin miedo y sin dolor. No pasa nada. Puedes decir: no, y explicar por qué, a lo mejor le haces un favor a muchos de tus compañeros. Aquí están 3 posibles razones por las que rechazar una reunión:
- Realmente no hago falta, soy un ‘por-si-aca’ así que ponedme al día después
- No puedo porque estoy ocupado/a en algo más prioritario pero va otro compañero
- No es el momento de tratar este tema, ya hay demasiadas cosas abiertas, vamos a hacer esta reunión cuando ‘esto o lo otro’ ocurra.
Organización de artefactos y recursos
Creo que todas las reuniones deben estar alrededor de recursos y artefactos de producto. Por ello, lo que considero una correcta gestión de los mismos puede hacer que la información esté actualizada, nuestros artefactos vivos y por tanto, el tiempo dedicado a crear nuevos documentos, presentaciones, etc. se reduzca considerablemente. Esto lo podemos conseguir de la siguiente manera:
- Tener todos los artefactos y documentos en un mismo lugar
- Que dicho lugar sea público
- Que esos artefactos se usen durante los eventos del ciclo de producto
Hace 4 años que en mi empresa cree una carpeta llamada ‘Product’ dónde están dentro nuestros artefactos y documentos. Hay sólo una. Está compartida con toda la organización.
- Ejemplo: cuando alguien no ha ido a la una reunión de revisión de KPIs, sabe que dentro de la carpeta hay otra con todas las presentaciones ordenadas por fecha, no pregunta, simplemente entra y se pone al día por su cuenta.
- Ejemplo: hay un sólo roadmap de producto que actualizamos siempre cuando hace falta, pero cualquier rol que quiera hablar del roadmap en una reunión sabe dónde está, sabe que está al día, sólo tiene que copiar y pegar en su presentación sin tener que interrumpir a nadie. Esto lo hice cuando vi que en la empresa había 5 visiones de producto diferentes, lo cual generaba un grave problema de comunicación, alineamiento de prioridades y falta de visión compartida. A día de hoy, una maravilla.
Poner orden ayuda a que todos sepamos dónde buscar y guardar la información que necesitamos rápidamente.
Organización de su trabajo
Como dije antes, creo que el Product Owner debe tener saber a organizar su trabajo de forma efectiva porque el resultado de esto impactará en las prioridades del equipo y finalmente, en el valor del producto. Con tanta reunión es fácil dejarse llevar por lo último que te han pedido super urgente para ayer, pero debes pararte, revisar todo en 360 grados y tomar decisiones con toda la información que tienes. Mi recomendación es la metodología Getting Things Done (GTD) de productividad personal. Os dejo una serie de artículos que escribí sobre como la aplico aquí y mis libros de referencia aquí.
Organización de su plan de mejora continua
Las habilidades de un Product Owner – y de cualquier profesional – pueden mejorarse continuamente y es su responsabilidad decidir si quiere mejorar o no. Como hemos visto en los artículos anteriores, hay cualidades, competencias, capacidades que se aprenden con el esfuerzo e interés de uno mismo: la manera de escribir emails, la manera de hablar en público, elaborar presentaciones, como ser más efectivo a nivel personal, metodologías de trabajo en equipo para desarrollar producto. Existen infinidad de temas que contribuyen a las responsabilidades de un Product Owner y por lo tanto se debe sacar tiempo para dedicarle a ellas. Yo intento sacar algunos huecos en mi jornada, por ejemplo si voy a preparar una presentación nueva, me doy una vuelta por Slideshare para coger nuevas ideas para visualizar la información y plasmar mensajes clave. Si tengo que preparar una charla en púbico, me voy al artículo que me guardé de referencia para recordar los puntos claves y así aplicarlos. Por otro lado, intento leer artículos de prensa sobre mi industria, ver los productos de mis competidores – aunque en mi empresa hay roles dedicados a esto que comparten novedades para que estemos todos al día del mercado. Invierto tiempo en leer libros, blogs, asistir a eventos y conferencias porque es cuando salgo de mi entorno cuando encuentro ideas frescas, de personas con otras experiencias, que además no están viciadas por mi entorno. Y así, poco a poco, paso a paso, detalle a detalle, se pueden mejorar las competencias de tu rol. El Product Owner se encarga de resolver problemas, y cuanto mayor sea tu caja de herramientas, más recursos disponibles tendrás y podrás proponer ideas más rápido.
La organización personal de un Product Owner impacta en el producto, el equipo y la empresa.
Os dejo los enlaces a los artículos que estoy escribiendo sobre el Product Owner:
- El Product Owner y la importancia de la comunicación
-
El Product Owner y su capacidad para analizar, priorizar y negociar
- El Product Owner y la gestión de los Stakeholders
- El Product Owner y la labor de conexión entre roles
- El Product Owner y cómo interpretar su rol
Vanesa Tejada 
Un pensamiento