En este nuevo episodio de Agile Latam, Veronica Martinez, Andrés Gateño y Ettiane Salamanca nos comentan a partir de su propia experiencia qué entienden por el mundo de Gestión de producto(Product Management).
Presentación
Veronica, se ha desempeñado en el distintos roles, como Product management, Scrum Master y Agile Coach, y se considera una agilista de corazón. Andres, ha trabajado como Business Analyst, desarrollador, y le encanta trabajar con gente y con agilidad, hoy en día trabaja como Agile Coach.
¿Por qué es importante la Gestión de producto?
Por la necesidad de conectar con los clientes, muchas veces nos enfocamos en la solución y no en la necesidad real. Nos falta conectarnos con el problema. Hoy más que nunca, tenemos que construir productos que sean para todos. Es importante considerar a los clientes finales y como resolver sus necesidades. Aún no creamos productos para todos los clientes.
Referencia de Anecdota – I’m not a cat
Muchas veces nos pasa que terminamos construyendo más para el negocio, y no tanto para el cliente. Este approach de algunas influye incluso, en los nombres que le ponemos a los equipos, no hablamos tanto de equipos de cliente, a propósito de un foco customer centricity. Por lo que es fundamental que tengamos interacciones con el usuario final y equipos acorde a esto.
¿Cómo llegan uds a la Gestión de Producto?
La curiosidad de entender y aprender mas, como se coordinan las áreas, son importantes los mentores también, que te motivan a entender que el software que estábamos creando era para cambiarle la vida a alguien.
Algo clave fue un curso con Marty Cagen, Jeff Patton, Teresa torres, era un mundo mucho más amplio como: Como cambiar el mundo.
Referencia de Story Mapping de Jeff Patton
Referencia de Output vs Outcome & impact
Algo que es importante mencionar, es la estrecha relación que debe existir entre el Scrum Master y el Product Owner y cómo puede potenciar al equipo.
¿Qué entienden por producto?
Podemos utilizar la analogía de un producto que está en una góndola del supermercado. En el caso del software, nos referimos a algo que le pueda valor a alguien(que le ayude a alguien a hacer algo). Por ejemplo algo que no sabía que necesitaba y ahora necesito. En la conversación también es importante que definamos lo que es valor. Jeff Patton, se refiere al outcome, qué viene después.
Referencia – Melissa Perri
Referencia – Marty Cagan
Son importantes y necesarias, hay que pensarlas bien y mantener un número limitado de ellas, pero lo principal es que nos permitan tomar decisiones. Tenemos que tratar de no llenarnos de datos que no nos permitan tomar decisiones. John Cutler menciona el flujo de data, insights y action.
Referencia: https://blog.amplitude.com/the-product-outcomes-formula
Es importante que nos visualicemos tomando decisiones con la data y no con el instinto ya que por algo buscamos la información. Es importante además que definamos qué es valor, y bajamos la escalera de inferencia. Muchas veces cuesta mucho tomar las decisiones, a partir de quien se tiene que hacer responsable por la decisión(Accountability).
En procesos de Discovery a propósito de que es una etapa de divergencia, sirve mucho acortar el tiempo en que tomamos decisiones, así creamos el hábito de tomar decisiones rápido. Algo que lo complementa, es armar una escena del crimen con toda la información disponible, así podemos medir nuestro aprendizaje y tomar nuestra decisión. Tomar decisiones cortas es un buen ejercicio económico sobretodo en organizaciones grandes. Troy Magennis además nos habla de la importancia de saber cuándo empezar más que para cuando va a estar.
¿Qué prácticas y/o Skills recomiendan?
Design Thinking y sus derivados como design sprint, Lean inception nos han funcionado muy bien, siempre contemplando el contexto. Pero en resumen la experimentación como herramienta principal.
Roman Pichler, entrega muchas herramientas. Es importante no meterse en los pragmatismo y enfocarse en entregar. El libro Testing business ideas de Wiley nos ha ayudado mucho últimamente también, recomendamos mucho esas ediciones.
Uno de los grandes problemas cuando ya hemos resuelto el discovery y el delivery, es como recibimos el feedback del usuario. Algo que también podemos utilizar es dual track, para paralelizar el discovery y el delivery, dos focos al mismo tiempo en el mismo equipo.
¿Cómo ven la gestión de producto dentro de la organización y en Latinoamérica?
A veces hay cosas que parecen obvias como discovery y validación, pero en muchos lugares aún no existe la empatía con el usuario. Falta mas intenon ecin probar, en pequeño, fallar y aprender.
La situación latinoamericana no la vemos tan ajena a otros lugares, quizás la brecha más grande se presenta en empresas nativas digitales. Algunas veces existe miedo a arriesgar y se prefiere ir a la segura, es decir, a la solución. Pero vemos mucha hambre y ganas de hacer cosas, a nivel de capacidad estamos a buen nivel. Es importante encontrar tu identidad para innovar y que los equipos muestren sus productos a su cliente final.
¿Cómo podemos iniciar este camino en la ?
Recomendamos un curso de Melissa Perri(Curso Online), que nos ayudó mucho. También charlas de Marty Cagan, “The Hero Camp” en español. Además podemos encontrar información en linkedin, medium. Los mentores nos ayudan a cuestionar y ampliar nuestra visión y son claves en un inicio. Georgina de Globant fue de gran ayuda en mi desarrollo. Finalmente depende mucho de nuestra curiosidad y de nuestras ganas de movernos.
Diccionario Agile
¿Qué es un MVP?
Andrés: Uno de los conceptos más confusos, de los que hay más definiciones, a mi la que más me gusta es la de Martin Cagan, el MVP test. No siempre tiene que ser una porción de un producto, podemos llevarlo a el experimento más pequeño posible. La idea es que el MVP no es uno solo, sino que es continuo.
MVP Dropbox
Q&A: ¿Cuál es la diferencia entre un proyecto y un producto?
Un producto es algo que no existe, en el que voy probando de a poco y experimentando. Un proyecto contiene una planificación con un objetivo en particular y cómo lo aplicamos depende del contexto, algo que ya conocemos y que podemos repetir. Los peleases o lanzamientos los podríamos ver como múltiples proyectos dentro de mi producto.
Para finalizar es bueno mencionar, no enamorarse de la solución, la idea es que tengamos la capacidad con el equipo de seguir validando lo que estamos haciendo. Nunca olvidarse del problema. No hay que tener miedo ni vergüenza de no tener siempre la respuesta, ya que lo estamos descubriendo y ser valientes si estamos construyendo un producto debemos arriesgarnos.
