Ya soy Product Owner, y ahora … ¿qué hago?

Sí, esto es algo que a mí me hubiese encantado poder leer de alguien cuando yo estaba iniciándome en el rol, o incluso que mis compañeros me comentaran algo de sus aprendizajes y cómo manejaron sus retos más fuertes. Sin embargo, no tuve mucha suerte en eso y tuve que encarar y decidir de la forma más rápida posible.

El ingresar a un nuevo rol no es algo que se vive todos los días, pero estoy seguro que se puede manejar sin frustrarte ni arrancarte los pelos durante las primeras semanas (sí, es algo que yo estaba a punto de hacer). En este tiempo, te quiero compartir:

• Cómo llegué al rol de Product Owner
• 3 lecciones que he ido reflexionando y que espero te den una perspectiva nueva para lo que viene en adelante.

Como bien señalo líneas abajo, toma lo bueno y pruébalo. No es necesario que sigas todo al pie de la letra, sino que encuentres también tu propia manera de hacer las cosas.

Dwight, the office representing

¿De dónde venía? ¿Qué tanto conocía de la posición? ¿Qué tanto influye esto?

• Analista de Negocio, conocía bien las métricas de negocio que se utilizaban y de los procesos core de la corporación.
• Ya conocía qué era Scrum y por lo menos cumplíamos las ceremonias con los equipos donde trabajaba, además del concepto del mindset agile.
• Conocía de los roles (PO, SM, Dev Team), pero no había interactuado con equipos de ingenieros y tampoco tenía background técnico, pero en la universidad me gustaba bastante la automatización a través de programación (hice un curso muy básico de eso).
• Tuve a cargo practicantes en su momento, donde ejercí de cierta manera un liderazgo.

No es el mejor background, lo sé. Pero aquí mi primer punto: no es necesario tenerlo, sino mas bien tener la predisposición para aprender y re-aprender esos conceptos que tenía en la cabeza. Es simple y cierto: Una cosa es cuando los llevas en un taller, y otra es cuando los intentas poner en práctica.

Recalco la palabra intentas, porque sé que fallé en varias ocasiones. Pero, yo siempre me presenté al equipo como alguien quien iba a cometer errores, pero iba a aprender rápidamente gracias a la colaboración de todo el equipo y a la misma transparencia que buscaba fomentar en el día a día (total, ¿esto es lo que el mismo mindset agile promueve, no?).

Por otro lado, algo que busco también cuando he entrevistado a diversos candidatos es el sentido lógico y crítico para encarar los problemas. ¿Suena bastante simple no? Solo pensar antes de actuar y listo. Créanme, hay mucho que aprender sobre este tema, ya que los problemas que vas a enfrentar son complejos y no te los han enseñado previamente en la universidad ni en algún otro trabajo. Pero tú vas a ser la persona que va a guiar varias discusiones con stakeholders y a presentar también el problema al equipo, es importantísimo que entendamos el background y analicemos por qué se ha generado. Gracias a las bondades que tiene la tecnología el día de hoy, no hay que ser unos gurús para saber cuándo algo no está funcionando. Y otro punto a tu favor, no estás solo en esto.

Por último, la disposición de no quedarte atrás ni tener una apertura a nuevas formas ni tendencias que existen. Esto es, la curiosidad. Ten algo muy presente, vas a crear y poner en vivo soluciones hacia usuarios, en un contexto en donde todo está evolucionando: nuevas empresas se fundan día a día, startups que obtienen financiamiento y nuevas tecnologías que salen a la luz. Estos usuarios consumen todas estas soluciones y además la tuya, ¿Cuál es la impresión que querrás darle a tus usuarios? ¿Cómo quieres ser recordado? ¿Cómo puedes aprovechar esto nuevo que está saliendo para beneficiar a tu usuario?

Cada una de estas características, para mí forman parte indispensable de lo que busco en un candidato al momento de ser entrevistado, y son algunas que miro más allá de lo que tenga su cv.

Ahora que ya estás en el rol y ejecutando, te quiero compartir otras 3 lecciones que aprendí en el camino:

Comparte claramente las Success Metrics

Toda historia o épica es una posible solución ante una necesidad o problemática del negocio, no siempre es la única que existe, pero si la estamos haciendo es porque creemos fuertemente que va a impactar significativamente en el menor tiempo posible. Por lo tanto, es una hipótesis, y estas siempre deben medirse con criterios de éxito (success metrics). La buena noticia es que la mayoría de estos criterios se calcula de forma numérica, y estos son valores que todo el equipo maneja universalmente, y si alguien no, te recomiendo que te tomes el tiempo de explicarle pues te ayudará muchísimo para alinear e ir empoderando al equipo más adelante.

Sea que el criterio de éxito tome o no tiempo en poder reflejarse o calcularse, es importante que todo el equipo esté de acuerdo en cuáles son, hay que manejar de forma adecuada la expectativa y ansiedad que muchos puedan tener por ver esos resultados.

Sobre esto, mis recomendaciones:

• Ilustra de la manera más gráfica y creativa el problema, y haz que todos estén en on board de esto, puedes apoyarte de herramientas colaborativas o incluso lúdicas como Mural, Miro y Kahoot.
• Toma en cuenta un espacio para que el equipo esté de acuerdo en cómo van a medir el impacto de lo nuevo que se está construyendo. Tú puedes llevar un boceto, pero la misma curiosidad del equipo te ayudará a entender otras perspectivas que podrás tomar en cuenta para que todos estén alineados en lo que quieren aprender.

Lanzar no es solamente pasar a producción

Después de todo el struggle que forma parte de la construcción y diversas pruebas que se han realizado en varios ambientes ya llegaste al stage donde se pasa a producción lo que tanto habías soñado. Sí, ¡al fin!

Lamentablemente, ese no es último paso.

Surprise!

Lo más importante en esta etapa es ver cómo el usuario está percibiendo el valor de lo acaban de construir. Y si es que no está teniendo respuesta, es la hora de retomar conversaciones con tu equipo y stakeholders para ver qué más se puede hacer en conjunto. Te sorprenderá ver cómo esa sincronización va a ayudar a entender puntos que no habías tomado en cuenta. Mi recomendación aquí es separar unos 15–30 minutos para trazar un plan de acción con las diversas áreas donde tú puedas llevar todo el contexto a través de data o insights que hayas recopilado. En el espacio, saltarán varios puntos de vista y así la conversación se enriquecerá mucho más para entender las causas raíz del problema. Lo interesante es que van a llegar a proponer algunas soluciones donde el squad tenga que intervenir, y saldrán unos fixes o hacks que se les pasaron por alto, pero pueden tener un gran impacto.

Claro está, que en el mundo ideal esto no debería suceder porque previamente ya has alineado este lanzamiento con varios stakeholders, pero recuerda que esto ha sucedido cuando el feature no estaba en producción. Es decir, era una hipótesis aún, pero ya en producción la historia cambia pues hay data que te está demostrando otro rumbo y sobre la cual debes tomar acción.

Co-crea junto al equipo

Para mí esto es de lo más importante (por eso lo dejé para el final 😅). Es de las lecciones que más impacto han tenido para el trabajo del día a día. Como contexto, en mi primera experiencia estaba ingresando a 2 equipos, donde la gran mayoría tenía +2 años trabajando en el mismo producto, siendo incluso algunos de ellos quienes habían fundado el producto digital. ¿Se imaginan todo el aprendizaje que ellos habían recopilado?

Recuerdo que en las primeras reuniones que tuve, donde estábamos planeando continuar el trabajo de una épica que ya venía desde antes que yo ingresara todo el equipo estaba desmotivado y de brazos cruzados. No hay que ser expertos para notar que había una incomodidad en la sala. Era de mis primeras reuniones así que pensé que estaba haciendo algo mal, pero cuando indagué un poco más en la razón de esta situación, alguien por fin dijo: “Ya hemos dicho muchas veces que esto no va a funcionar, el usuario final no va a entender esto, encima el impacto es bastante pequeño porque son pocos los beneficiados por esto.”

Una vez que la persona mencionó esto, miré que todos los demás miembros del equipo asintieron la cabeza, y claramente estaban todos de acuerdo. Nadie le tenía fe al feature y el equipo venía trabajando +3 sprints en esto. En serio, valoro muchísimo que esa persona haya decidido hablar en ese momento, a pesar de lo incómodo que pudo haber sido para muchos, la transparencia y sinceridad es de lo mejor que puede existir en un equipo.

Mirando hacia ese momento, se puede accionar de diversas maneras, la verdad la mía no fue de las mejores, pero toda la situación me dejó un mensaje claro: Este feature no había siquiera sido comprado internamente por el equipo, ni siquiera había sido co-creado con ellos, solo impuesto para que ellos se encarguen de desarrollarlo porque a alguien se le ocurrió realizarlo. ¿Te imaginas todo el conocimiento que se desaprovechó? ¿Qué se pudo haber hecho en todo ese tiempo para impactar al negocio?

Dejo esas últimas reflexiones y más para una segunda parte, donde ahondaré un poco más en la construcción con el equipo (hay muchos libros que hablan de esto, ahí veremos qué dicen algunos🚀)

Espero que si has llegado hasta esta última parte, te sirva para la nueva experiencia que estás por asumir, y si ya estás en ella, como una nueva perspectiva a tomar en cuenta.