Trabajando con superhéroes: Mi experiencia como Product Owner en Interbank

Eran las 9 de la noche y mi celular comenzó a sonar. Me llamaba Jorge Higa, el PO de Interbank.pe. Sin duda, era extraño recibir una llamada de trabajo a tan altas horas de la noche, pero contesté de inmediato para atender lo que podría ser una posible emergencia. Y vaya que lo fue: Jorge me explicaba que, después de 9 exitosos años en Interbank, había decidido migrar a otra empresa en búsqueda de nuevas oportunidades. Al mismo tiempo, él me contaba que estaba recomendando mi perfil para poder ocupar su lugar.

Con solo un año y algunos meses en Interbank decidí tomar el reto porque ansiaba aprender algo nuevo y porque de alguna forma me había preparado en los últimos 10 años para este momento (sin saberlo). De cualquier manera, en el mismo instante que aceptaba la oferta no estaba completamente seguro de lo que estaba haciendo, pero mi convicción sobre lo que este paso significaba para mi carrera y la confianza que depositaron mis jefes me ayudaría a seguir adelante.

De la noche a la mañana, me convertí en el Product Owner de la Web Pública de Interbank, y durante casi dos años enfrenté a diario los retos más difíciles de mi carrera profesional. Luchamos junto al equipo varias batallas, ganamos algunas y perdimos otras, pero en el balance puedo decir que juntos hicimos historia. En las siguientes líneas, no quiero aburrirlos repitiendo todos nuestros éxitos o crear una guía definitiva para ser un PO infalible. Por el contrario, quisiera compartir algunos aprendizajes que fui acumulando en este tiempo con aquellas personas que recién empiezan en este rol o tienen interés en este.

La mejor teoría es la que sirve en la práctica

Sí, todos hemos llevado al menos un curso de la metodología Scrum y hemos leído sobre el rol que debería cumplir respectivamente un Product Owner, un Líder Técnico y un Scrum Master. Y todos también hemos sentido la misma frustración al darnos cuenta que nada de lo que dicen esos artículos o libros se cumple en realidad. ¿Es que acaso hemos fallado?

La teoría está pensada para guiarnos en la ejecución práctica de una metodología, pero jamás debería convertirse en un dogma incuestionable. En reiteradas ocasiones, en algunas con más tensión que otras, discutí con el equipo sobre cuáles deberían ser nuestros respectivos roles y qué diferencias encontrábamos en lo que hacíamos en el día a día. Sin embargo, nuestras discusiones nunca apuntaron a generar conflicto, sino a llegar acuerdos y buscar un equilibrio itinerante. Probar y probar, hasta hallar un balance.

Algunos dirán que el PO debe tener una base técnica fuerte, participando de definiciones que van un poco más allá de lo funcional. Otros dirán que el Líder Técnico debería ser quien defina realmente el cómo. Me parece que no hay una fórmula perfecta. Nosotros llegamos a descubrir nuestras fortalezas y debilidades como equipo, y luego aprovechamos lo mejor que cada uno podía ofrecer. La práctica te demostrará que por encima de la teoría y los roles, siempre podrás negociar y llegar a un entendimiento con tu equipo de trabajo. Busca la forma de obtener el equilibrio que necesitan.

Dedica energía a gestionar tu tiempo

Un día eres analista con funciones claras, y al siguiente eres PO de un proyecto donde sientes que todos los días te la juegas y no alcanza el tiempo. ¿Cómo puedo hallar espacio para construir el día a día de mi proyecto y también pensar en el futuro del mismo? ¿Cómo me aseguro de priorizar bien mi backlog si tengo que medir en paralelo los resultados de lo que voy logrando? ¿Cómo puedo asegurarme de redactar bien las historias de usuario si tengo que participar de las ceremonias de planning, refinamiento y retrospectivas? Sin duda, estas preguntas no tienen fácil respuesta, y lo clave aquí será que dediques energía para gestionar de forma creativa tu tiempo.

¿No recuerdas lo que pactaste en la última reunión con el stakeholder? Más vale que empieces a enviar tus propias actas por correo, y no dependas de los demás para esto. ¿Quieres tener reuniones más cortas y efectivas? Quizás sea buena idea que prepares unos slides previos a la reunión para que todos entiendan lo que necesitas en pocos minutos. ¿Te distraen mucho en la oficina? Podrías probar aislarte algunas horas a la semana para avanzar más rápido con tareas que requieren concentración. ¿Respondes cada uno de tus mails apenas eres notificado? Quizás sea mejor destinar solo algunos minutos fijos de tu día a responder todos los mails y luego continuar con las tareas importantes. En suma, debes hallar tu propio método y no convertirte en una víctima de las circunstancias.

Prepárate para convivir con la ansiedad

El refinamiento se desarrollaba entre risas y buen humor. El detalle del alcance fue revisado, pero al aproximarse el final de la reunión, el stakeholder lanzó una pregunta incómoda que dejó a todos en silencio. “¿Para cuándo va a estar la funcionalidad en producción?”, consultó. Estoy seguro que esta historia te suena familiar y que también has repetido lo mismo una y otra vez: definir una fecha exacta para el lanzamiento de un nuevo desarrollo va en contra del marco metodológico Scrum, utilizado sobre todo para la gestión de proyectos de alta incertidumbre. Bien, ¿ahora cómo les hacemos entender al resto todo esto?

No te voy a mentir: a mi tampoco me entendieron. Lo único cierto en la vida de un PO es que siempre estará rodeado de personas ansiosas. La velocidad del cambio tecnológico, la agresividad de la competencia y la urgencia por lograr resultados son variables que constituyen un escenario perfecto para que nuestros stakeholders se mantengan nerviosos y en búsqueda de respuestas. Y entonces, ¿cómo lo puedes resolver? Simple: brinda visibilidad, mucha visibilidad. Exagera si es preciso. Crea un backlog compartido para cada uno de ellos y que también participen de su gestión. Lanza fechas estimadas para tus nuevos desarrollos, y resalta que son tentativas. Coméntales de las dificultades que encuentras y de tus últimos progresos: mantenlos al tanto de tu lucha. Cualquier herramienta es válida mientras tú y el stakeholder estén siempre sobre la misma página, y puedas evitar las decenas de correos/llamadas ocasionadas por la ansiedad. En mi experiencia, un stakeholder estará más disconforme por no tener visibilidad sobre lo que está pasando, que por un entregable que no se entregó en la fecha comprometida.

El MVP ideal es el que está en producción

“Nos gustaría que esta funcionalidad lance fuegos artificiales, deje al cliente satisfecho, genere un impacto en el negocio y salga a producción mañana”, dijo un entusiasmado sponsor al conversar con el PO durante un refinamiento. Con la misma pasión, este último le contó esta gran idea al Líder Técnico. De pronto, la preocupación invadió el rostro de ambos. “Hoy no contamos con la tecnología, ni la infraestructura para lograrlo”, sentenció. En seguida, el PO se cuestiona: ¿cómo diseñar el producto del futuro si no tengo todos los recursos hoy?

La teoría nos dice que el mejor MVP es aquel entregable que, con el mínimo esfuerzo, nos permita recolectar el máximo aprendizaje de nuestros clientes. Suena sencillo, pero en la práctica descifrar esto puede ser algo complicado. En mi experiencia, los mejores MVPs son los que llegan a estar en producción y generando valor, así que lo primero en lo cual debes enfocarte es recortar (y recortar) el alcance. Dalo por hecho: esperar a las condiciones ideales para lanzar un MVP es un ingrediente clave de una receta llamada fracaso.

Una vez que has digerido esta importante premisa, lo que debes hacer a continuación es ampliar tu conocimiento al máximo sobre la tecnología que usa tu producto para así poder plantear soluciones creativas. Por último, y luego de tener claridad sobre el producto mínimo viable que necesitas, deberás convencer a los sponsors que tu idea, si bien no es una solución definitiva, está aportando valor al negocio y que los primeros resultados te permitirán escalarla al siguiente nivel. Cuando ellos hayan aceptado, estarás en camino a la gloria.

Aprende a decir más seguido “NO”.

En algún momento le llamé a este proyecto “La Fábrica de Sueños” y la verdad es que no estaba exagerando. Cada stakeholder que se acercó alguna vez a pedir un nuevo desarrollo venía siempre con el mismo brillo en los ojos: deseoso por contarle a su jefe en unas semanas más que aquella idea que bosquejó en unos slides o papel hace un tiempo ya era una realidad visible en la web.

Todo se puede hacer. El equipo de tecnología te lo recordará siempre; sin embargo, tu rol como PO será siempre priorizar las ideas con mayor impacto en el negocio, y despriorizar, en consecuencia, aquellas que son más descabelladas. Si tu foco no está claro, terminarás con un cuadro de estrés clínico y odiando tu proyecto. Eso te lo garantizo. Sin importar caras largas, reclamos no justificados, e inclusive quejas con tu jefe tendrás que decir muchas veces NO. Pero no me malinterpreten: no se trata de decir NO por puro gusto. El criterio para poder decirlo es algo que irás desarrollando con el tiempo, no obstante, la mejor base para tomar decisiones la tendrás siempre que conozcas el negocio y respires la realidad de la empresa en la que te desenvuelves.

Define para qué quieres poder

En los últimos años se ha compartido la figura del PO como la del “superhéroe” en el imaginario de las comunidades ágiles. Una imagen que ha vuelto muy atractivo este rol en el mercado y cuya metáfora no comparto del todo (lo explico más adelante). Es inevitable, sin embargo, no haber percibido en las reuniones con el equipo y otros stakeholders que “el PO tiene la última palabra”. Enfrentado con esta realidad, hace muchos meses reflexionaba sobre este poder que le es conferido al Product Owner para liderar el proyecto.

Me pregunté muchas veces si realmente me sentía a gusto con este “poder”. Si en algunos meses posteriores iba a querer más poder o si, por el contrario, iba a rechazar todo el que me estaban brindando. Tras pensar mucho al respecto, y con ayuda profesional, me percaté que la pregunta que tenía que hacerme era realmente para qué quería todo ese poder. Es la misma pregunta que les invito a que se hagan ¿Para qué quieres poder? ¿Poder para llevar a un equipo a rendir con su máximo potencial? ¿Poder para darle a un grupo de personas algo en que creer? ¿Poder para cambiar la vida de los clientes? ¿Poder para cambiar la historia de la empresa donde trabajas? Respondan a esta pregunta y tengan por seguro que se sentirán liberados y hallarán la motivación que incluso va más allá de su rol como Product Owner.

En los siguientes días asumiré otro rol en Interbank y escribo estas líneas para cerrar de forma oficial este capítulo de mi vida personal y profesional que me ha permitido crecer muchísimo. Estoy muy agradecido con todas las personas que confiaron en mí y que me acompañaron a lo largo de este accidentado y divertido viaje. Ningún resultado podría haber sido posible sin ustedes. Hoy estoy más convencido que los equipos que logran cosas extraordinarias, no son aquellos donde el Product Owner es el único que se pone la camiseta de superhéroe, sino aquellos en los que sus diversos miembros (Líder Técnico, Scrum Master, Analistas, Devs, QAs) se la alternan a diario y empujan a todos al siguiente nivel. Yo mismo lo comprobé durante los días que trabajé junto al equipo de Interbank.pe.