Por Martin Alaimo
El trabajo del PO es esencial para el éxito del producto, pero aunque no es un tópico muy discutido, existen desafíos que van más allá del Product Backlog. Esos desafíos responden a temas menos explorados pero igualmente vitales: desde lo que impacta la toma de decisiones en diseño hasta el aspecto emocional en los usuarios. Veamos cuáles son esas dimensiones.
Ansiedad frente a múltiples posibilidades de diseño
El primer aspecto tiene que ver con un determinado rasgo cultural que he visto más de una vez en diferentes clientes: la necesidad de complicar por demás las cosas. Por ejemplo:
Quisiera una aplicación que me avise cuándo mi vuelo está demorado. Y que también me diga si hay otros vuelos disponibles para cambiar mi ticket. Y en tal caso, qué precio tendría el cambio y si la cancelación de mi vuelo demorado incurrirá en penalidad. O si hay algún vuelo de la misma aerolínea que me lleve al mismo destino, aunque sea con otra conexión. Y, ya que estamos, que me presente opciones de conexiones con otras aerolíneas de la misma alianza de la aerolínea con la que tenía el ticket original.
Y cuando ya nos parece demasiado:
Pero ¿qué pasaría si hay disponibilidad en otro vuelo, pero luego de cambiarme ese vuelo vuelve a demorarse? Mejor que la aplicación me muestre la probabilidad de demora de cada vuelo alternativo, basado en las estadísticas y la meteorología.
Y listo. Bingo!
Por oposición, en el Agile Manifesto, se lee uno de los principios, que en mi experiencia en cursos y empresas, es de los más difíciles de comprender (o aceptar):
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial
Son tres cuestiones las que nos invitan a llevar a terrenos de mayor complejidad las cosas mucho más de lo necesario y que el Scrum Product Owner debe poder manejar:
1.Pido por las dudas: Una vez iniciado un proyecto, tradicionalmente, cualquier cambio al alcance debe atravesar un proceso de control de cambios. Este proceso es, en muchos casos, más bien una barrera infranqueable para que aquellos hallazgos producto del aprendizaje no logren impactar el alcance y queden afuera. Entonces ¿qué hago? Pido en forma anticipada, por las dudas, cosas que ni siquiera tengo seguridad si alguna vez las voy a necesitar.
2. Más es mejor: Nos han enseñado que cuanto mayor sea la oferta a nuestros clientes (usuarios en estos casos), mejor. Darles mayores posibilidades de acción a los usuarios de nuestros productos o servicios les brinda una mayor satisfacción.
3. Miedo a la decisión: La palabra decisión tiene sus raíces en el verbo que se usaba en latín para describir la acción de talar árboles y tiene el sentido de separar algo (lo elegido) del resto (lo descartado). Cuando me decido por algo, lo estoy separando del resto de las opciones, y por lo tanto, esas otras opciones las estoy descartando, serían como las ramas del árbol que estoy talando. ¿Y el miedo? Es a equivocarme y descartar cosas valiosas, entonces, mejor no decido, no descarto, no talo el árbol y pido todo.
Un artículo en "The Guardian" titulado por qué tantas opciones nos generan estrés se alinea, desde mi visión, a los dos últimos puntos del pequeño listado anterior: más es mejor (FALSO) y miedo a la decisión (VERDADERO).
El artículo habla acerca de la ansiedad a la que nos vemos sometidos cuando se nos presentan muchas opciones para elegir. Por ejemplo, hicieron un experimento promocionando mermeladas en un supermercado, pusieron un stand con 6 opciones y otro stand con 24 opciones de mermeladas para que los compradores prueben sabores y obtengan un cupón de descuento en el caso de comprar algún sabor. El 30% de las personas que fueron expuestas al stand con 6 sabores compraron mermelada, pero solo el 3% de las personas expuestas al stand con 24 sabores compraron mermelada. ¡Un porcentaje diez veces menor!
Una de las conclusiones del artículo señala la presencia del miedo a elegir una opción incorrecta entre varias alternativas. El problema se amplía cuando se incrementa la cantidad de opciones para elegir, porque el riesgo de equivocarse es mayor y nos paraliza y genera ansiedad.
En definitiva, el Scrum Product Owner debe estar muy atento a la dificultad que se presenta a la hora de simplificar debido a la incapacidad de decisión, el miedo a lo que perdemos y la creencia popular de que más es mejor.
Certified Scrum Product Owner (CSPO)
Qué tipo de preguntas poderosas hacer para indagar sobre el producto
A tus usuarios no les importa si tu producto es lindo, si tiene muchas funciones, ni siquiera el tamaño. Lo que mas les interesa es solucionar su necesidad.
El desarrollo tradicional orientado al producto parecería más una cuestión de fe que de buen hacer. Que el producto encaje con las necesidades reales del usuario es muy difícil. Esto es debido a que durante todo el proceso de desarrollo de un producto no se conocían las auténticas necesidades de los usuarios y el contacto que se ha mantenido históricamente con ellos es escaso.
Pero los enfoques actuales han dado un giro a esta realidad y una apuesta hacia aprender de los propios usuarios para diseñar y presentarles el producto que necesitan de verdad, adaptándose continuamente, con especial foco en las primeras etapas.
La palabra clave en todo esto es: aprender. Hoy nos guían procesos de aprendizaje continuo en los que el contacto con los usuarios es abundante y la información que nos proporcionan es la brújula principal para el desarrollo y evolución del producto. Por eso es importante que les hagas las preguntas correctas.
Indaga sobre qué necesita resolver tu usuario:
- ¿Qué es aquello que no podría vivir sin lograr?
- ¿Cuáles son los problemas que intenta solucionar?
- ¿Qué necesidades emocionales intenta satisfacer?
Descubre qué beneficios quiere obtener:
- ¿Qué aspecto de su vida está buscando facilitar?
- ¿Qué consecuencias sociales positivas persigue?
- ¿Qué significa 'éxito' para tu usuario?
Identifica qué dolores o preocupaciones quiere reducir:
- ¿Qué cosas lo estresan?
- ¿Qué no le permitiría dormir por las noches?
- ¿Cuáles son los errores comunes que comete?
Usando estas preguntas poderosas puedes diseñar productos que “sirvan”, que realmente resuelvan necesidades y puedan ser exitosos.
El desafío ético de las emociones y cómo afectan la motivación en los usuarios
El primer paso es entender la diferencia entre las emociones y los disparadores.
Humberto Maturana sostenía que las emociones son predisposiciones para la acción. Es decir, condicionan el universo de posibilidades que tiene una persona mientras está atravesando una determinada emoción.
Por ejemplo: no le pedirías un aumento de sueldo a tu jefe o jefa si está enojado/a. Esto es porque aumentarte el sueldo a ti no es una posibilidad para él o ella en ese momento.
Nir Eyal identifica como disparadores a los llamados a la acción que experimentan los usuarios de productos. Su repetición en el tiempo es lo que forma hábitos en esas personas.
Visto desde un producto, podemos clasificar en externo o interno al disparador inmediato que ha hecho que una persona haga uso del mismo. Los disparadores externos pueden ser anuncios, botones, landing pages, recomendaciones, invitaciones, newsletters, notificaciones, etc. Mientras que los internos son las emociones.
Los productos digitales exitosos son expertos en la identificación de estos disparadores internos. Uniendo esto con Maturana, podríamos decir que el éxito de un producto digital radica en posicionarse como la primera opción frente a las emociones de sus usuarios.
Un ejemplo podría ser:
* Cuando tienes dudas usas Google.
* Cuando buscas entretenimiento, entonces Instagram.
* Pero si sientes aburrimiento, entonces Netflix.
* Y si sientes estrés, entonces Calm.
* Pero cuando sientes que te puedes estar perdiendo de algo, entonces Twitter.
Pero cuidado. El lado oscuro es que tienen más tracción aquellos productos que se enfocan en capitalizar las emociones negativas de sus usuarios. Esto es porque los llevan a volver recurrentemente en busca de alivio emocional que genera inicialmente más apego pero podrían generar adicción tecnológica a largo plazo.
Los Scrum Product Owners y Agile Product Managers avanzados se aseguran de que su producto resuelva necesidades genuinas de sus usuarios y/o clientes. En otras palabras, que sus productos sean analgésicos para traer bienestar a sus usuarios sin manipulación.
Los indicadores de cumplimiento de los objetivos de producto
¿Nos habremos equivocado durante tantos años? Es simplemente una pregunta que se me viene a la mente con respecto a la forma en la que medimos el progreso de nuestros proyectos, tanto sea de la forma tradicional como desde el punto de vista Ágil.
El Manifiesto Ágil, define que la principal medida de progreso es el software funcionando. Extrapolado a otros ámbitos fuera del software, sería algo así como "la principal medida de progreso es el producto funcionando".
Estoy cada vez más en desacuerdo. Desde siempre estuve en desacuerdo con la interpretación de éxito de las maneras tradicionales de gestión que miden el cumplimiento del alcance, el tiempo y el costo, sin importar qué tan robusto, integrado, funcional y útil es lo que se está construyendo. Y además, creo que la definición de progreso Ágil (software funcionando) responde a una necesidad coyuntural de los equipos de desarrollo: la postergación de la integración y pruebas punta a punta del software siendo construido. El hecho de no ver software funcionando sino hasta el final de los proyectos ha hecho que el riesgo de retrabajo por falta de calidad sea demasiado grande como para considerar que se está avanzando. Este síntoma también conocido como el síndrome del 90%, una falsa sensación de progreso, ya que el progreso está basado en información subjetiva y no en la realidad.
Ahora, lo que a mi me parece es que ambas medidas hablan de las actividades que estamos haciendo y no del qué tan útil es el producto que estamos construyendo. Por lo tanto, yo puedo entregar en tiempo, en forma y cumpliendo con el alcance un producto inútil. Inclusive, aunque lo construya en iteraciones (sprints) y me asegure que ese producto funciona al final de cada iteración.
En un contexto en el cual no tengo feedback real del negocio y/o no mido el impacto del producto en mis objetivos de negocio, voy a seguir teniendo una falsa sensación de progreso, seguramente no con respecto a los aspectos técnicos del producto, pero posiblemente sí con respecto a los objetivos de negocio que estoy buscando alcanzar.
Veamos un ejemplo concreto:
En una empresa estaban desarrollando un producto web con el objetivo de incrementar las ventas mediante el canal digital-online de ciertos productos. El alcance constaba de la adición de una propiedad a ciertos productos para que aparezcan como destacados en el sitio web, algo común, nada de otro mundo.
Si midiéramos de manera tradicional, el éxito estaría alcanzado al lograr el desarrollo de esta funcionalidad, dentro del tiempo y presupuesto esperado. Punto.
Si midiéramos de manera ágil, el éxito estaría alcanzado al entregar esta funcionalidad funcionando en el sprint comprometido. Punto.
¿Y qué pasa si esa funcionalidad no incrementa las ventas? ¿Realmente fue un trabajo exitoso? Yo lo dudo.
Hay que insistir en desafiar los supuestos, cada vez tiene que resultar más natural preguntarse: ¿Cuál es la hipótesis en la cual me estoy basando para llevar adelante esta iniciativa? ¿Cómo voy a medir el impacto de mis acciones y corroborar mi hipótesis?
En el caso de los productos destacados, sería algo así como:
- ¿Cuál es la hipótesis en la cual me estoy basando para llevar adelante esta iniciativa? No logramos vender la cantidad esperada de ciertos productos porque las personas que visitan la página no los encuentran o no se sienten atraídas por la manera en la que los estamos presentando. Si los destacamos y hacemos más accesibles, las ventas se van a incrementar.
* ¿Cómo voy a medir el impacto de mis acciones y corroborar mi hipótesis?
Al destacar ciertos productos, debería incrementarse en un 20% las ventas de los mismos por el canal digital-online al cabo de un mes.
Entonces, al cabo de un mes voy a poder decir si mi proyecto fue exitoso al corroborar el incremento mayor al 20% en las ventas de los productos destacados, y ya no voy a pretender que el éxito haya sido alcanzado sólo por entregar el alcance, dentro del tiempo y el presupuesto, ni tampoco por haber entregado un incremento funcionando del producto.
Formas de medir estos impactos hay muchas, por citar algunas: Impact Mapping u OKRs - Objectives and Key Results (la medida de objetivos impulsada por Google).
Para seguir leyendo:
El trabajo del Product Owner en el desarrollo ágil
Qué KPIs y métricas de productos digitales priorizamos en Alaimo Labs
Las bases para implementar Agile Product Management