Aquí entramos en lo que hemos llamado ese mínimo producto viable de habilidades blandas necesarias en todo maletín de herramientas del buen cocinero para fabricar esa Buena Priorización (en el enlace, la parte I). Es el ingrediente secreto.
Cuando hablamos con un stakeholder sobre esa brillante idea que han guisado para vuestro producto es importante hablar desde la necesidad. Por ejemplo:
[STAKEH.] Hay que meter un botón de favoritos.
[BUEN PM] Bueno, cuéntame más.
[STAKEH.] Nada más, hay que meter ese botón.
[BUEN PM] Entiendo, ¿crees que nuestros usuarios necesitan ese botón? ¿Crees que aumentará la cesta media?
[STAKEH.] ¡Claro! ¡Yo soy usuario y veo más que necesario! ¡Compraría más sin duda!
[BUEN PM] ¿Por qué?
[STAKEH.] Porque nunca tengo los artículos que me gustan a mano cuando quiero comprarlos.
[BUEN PM] ¿Por qué?
[STAKEH.] Porque cuando encuentro algo que me gusta lo tengo que meter en la cesta y con el tiempo se borra.
[BUEN PM] ¿Cuántas veces usaste el producto en el último mes?
[STAKEH.] ¡Muchas veces!
[BUEN PM] ¿Y la semana pasada?
[STAKEH.] Bueno, dos veces.
[BUEN PM] ¿En esas ocasiones usaste el truco de la cesta que comentabas?
[STAKEH.] No, bueno, la semana pasada no.
[BUEN PM] Es una idea interesante, la incluiré en el backlog para estudiarla.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Aquí surgen varias cuestiones interesantes tratando de indagar en la necesidad del botón de favoritos:
¿Es realmente necesario para nuestros clientes? ¿Realmente aporta valor al negocio? ¿Podemos solucionarlo arreglando el time-out de la cesta? ¿Podemos medir cuánta gente hace ese truco de la cesta? Indagar en la necesidad es fundamental a la hora de coger esta funcionalidad y colocarla en el orden correcto en nuestro backlog.
La necesidad, en ese caso, quizá no era ese botón de favoritos, sino más bien poder tener un lugar donde guardar artículos del catálogo para poder revisarlos en otro momento y ejecutar la compra.
De la misma forma que indagamos en la necesidad de esta stakeholder, también debemos indagar y profundizar en las necesidades reales de nuestros clientes, en las necesidades de negocio y en las necesidades del equipo de producto.
La mejor forma de saber si estamos hablando desde la necesidad es preguntarnos ¿estamos hablando de la solución, del cómo, o estamos hablando de un objetivo aspiracional? ¿Del qué?
Cómo resolver esa necesidad es harina de otro costal, conversaciones en las que es necesario involucrar a más compañeros para estudiar todas las soluciones posibles a esa necesidad.
A menudo ocurre que un mal product market fit se debe a una mala aproximación a la solución debido a una mala investigación de la necesidad. Y he dicho "a menudo", que un mal product market fit también se puede deber a que estamos vendiendo sushi en un market vegetariano (contexto). En este punto es donde entra la cultura lean del error.
Si estamos preparados mentalmente para el error, y reaccionamos rápido, podemos cambiar el sushi por maki de tempura de verduras con aguacate y te haces con el market. Prueba, falla, aprende y vuelve a probar, ciclos cortos y mentalidad fuerte.
Estamos educados hacia el éxito, sin prestar atención al error y esto es la primera causa de fracaso.
Necesitamos desaprender, cultivar nuestro huerto mental con ricas hortalizas de resiliencia, tolerancia a la frustración, espantapájaros para los sesgos y guadaña para los miedos.
Mentira esto último, al miedo no hay que eliminarlo, otra creencia limitante, hay que hacerse su mejor amigo, persuadirlo para que no se meta en nuestras decisiones. Para fomentar la cultura lean del error lo mejor es desarriesgar, guiarnos por el instinto y datos, muchos datos, dame más datos que apoyen nuestras decisiones.
¿Qué herramientas puedo usar?
Para resolver este enigma me voy a apoyar en el gran artículo escrito por Andrew Quan, Head of Product en Littlepay, donde crea un framework para elegir frameworks. Una propuesta sin fisuras.
Voy a tomar las claves principales del artículo y me voy a quedar con las herramientas que, en mi opinión, son las que más pueden ayudarnos a conseguir esa Estrella Michelín (aún así, no podéis dejar de leer el artículo es el catálogo perfecto donde elegir los mejores cuchillos de chef).
En el framework que propone Andrew ubica las herramientas de priorización en una gráfica con el nivel de validación de usuarios finales en el eje Y, y el tipo de datos usados para priorizar en el ejeX. En base a esto categoriza un total de 13 frameworks de priorización en Básico, Intermedio y Avanzado. A lo largo del artículo os va guiando y propone preguntas para ir ajustando el tiro sobre el tipo de cuchillo conveniente para tu backlog.
“Una vez que hayas elegido un par de frameworks que puedan adaptarse a tu cultura y necesidades de análisis de datos, familiarízate con el funcionamiento interno del framework y simplemente pruébalos. Recuerda: no existe una decisión perfecta y elegir el marco adecuado que se adapte a tu equipo es un proceso iterativo”, nos dice Andrew.
Voy a tratar de resumir mucho mis herramientas favoritas para que os hagáis una idea de qué pinta tienen esos cuchillos y podáis elegir uno. Una vez que tengáis uno o dos frameworks, os animo a que profundicéis y experimentéis:
Cost of Delay and Weighted Shortest Job First (WSJF)
Este framework se basa en una fórmula matemática. Todavía no hemos llegado a cruzar la línea, John Nash.
Esta fórmula divide el CoD (Coste de Desarrollo) entre el Job Size (duración o tiempo que lleva implementar) y obtiene como resultado el trabajo más corto ponderado primero (Weighted Shortest Job First, WSJF), el incremento más pequeño y valioso en el que debe trabajar primero. Para calcular el CoD suma las variables Valor de Usuario-Negocio, Urgencia o Criticidad, Valor de reducir riesgos - habilitar oportunidades.
- Ventajas: pone foco en ítems pequeños y valiosos, cortoplacistas pero de gran impacto apoyándose en nuestra capacidad para hacer buenos mvp’s, es cuantitativo (prácticamente científico).
- Contras: voy a copiar lo que dice Andrew porque no puedo expresarlo mejor, “además de utilizar muchos cálculos, el framework se parece mucho a tu ex loco, muy pedante, por lo general requiere una cierta cantidad de atención a los detalles y puede requerir un alto mantenimiento. A menudo, a sus compañeros pueden no gustarle debido a su complejidad”.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
RICE Scoring
RICE es un sistema basado en cuatro criterios, Reach o Alcance (ej. amplitud de usuarios), Impacto (ej. nivel de impacto por usuario), Confianza (ej. porcentaje de seguridad que te ofrece), y Esfuerzo (ej. alto, medio, bajo). Al medir estos cuatro criterios, los metemos en una coctelera y sale un resultado.
La coctelera es la siguiente fórmula:
[(Alcance * Impacto * Confianza) / Esfuerzo]
- Ventajas: ayuda a comparar ideas abstractas bajo los mismos criterios, sólo cuatro.
- Contras: los factores de la fórmula están predefinidos, no se pueden adaptar a tu menú.
Kano Model
Modelo basado en la satisfacción del cliente según una perspectiva funcional del producto con la feature a priorizar y según una perspectiva disfuncional o producto sin la feature a priorizar.
La satisfacción se mide respondiendo a la perspectiva funcional y disfuncional con: me gusta, esperable, neutral, puedo aceptarlo y no me gusta.
La combinación funcional/disfuncional con cada una de las respuestas devuelve una matriz donde cada combinación recibe uno de los siguientes tipos:
Obligatorio/Esencial, Lineal, Excitante, Contradictorio, Cuestionable, e Indiferente.
Una vez que tenemos cada historia de usuario categorizada visualizamos los resultados en el diagrama de Kano.
- Ventaja: es más visual y cualitativa, no tan enfocada en datos.
- Contras: Deja fuera el coste, el esfuerzo y el resto de atributos que hemos comentado.
Amplía tus conocimientos sobre el Modelo Kano con este artículo sobre priorización el backlog o descargando el libro Agile Product Management
Buy-a-Feature
Más que un framework este cuchillo lo considero un taller o dinámica.
Con una lista de funcionalidades a priorizar se proporciona un precio a cada una. Cómo asignar ese coste varía en función de lo que necesitemos o queramos establecer.
Los participantes del taller Buy-a-Feature (equipo de producto, stakeholder/negocio, y quien vosotros queráis o penséis que aporta valor) tienen un presupuesto establecido y deben comprar las funcionalidades que quieren tener disponibles en la próxima iteración del producto, justificando su prioridad.
- Ventaja: Comprar con un presupuesto pone de manifiesto las limitaciones a la hora de desarrollar y colaborar en la construcción genera compromiso (efecto IKEA).
- Contras: No tienen en cuenta una validación con el usuario, las funcionalidades seleccionadas pueden responder a intereses individuales.
Story Mapping
Es un modelo de visualización de historias de usuario que permite encajar las funcionalidades en un roadmap claro. La prioridad se establece de arriba a abajo siendo arriba los temas más prioritarios. Story Mapping pone el foco en el valor para el usuario y para la empresa.
- Ventajas: visualización y alta colaboración, representación cualitativa.
- Contras: Al ser cualitativo se olvida de medir el esfuerzo y el impacto.
Matriz de MoSCoW
Es un modelo basado en categorizar cada funcionalidad en cuatro tipos:
Must (debe ir en el MVP), Should (debería ir en el MVP pero no es crítico), Could (primeras eliminadas si corre riesgo el MVP), Won’t (no las quiero ni en pintura).
Se organizan las funcionalidades en esta matriz teniendo en cuenta los atributos que consideremos.
El Won’t, aunque parezca innecesario o inútil, al contrario es bastante importante usarlo, nos ayuda a visualizar aquellas funcionalidades a las que hemos dicho que no, por que no han superado la fase de discovery o hemos fallado, y también para establecer todo lo que no queremos que sea nuestro producto.
- Ventajas: funciona bien si conocemos los atributos de las funcionalidades y además tenemos estas funcionalidades con un mínimo de refinamiento de antemano.
- Contras: Es subjetivo y si se hace con equipos que piensan igual o parecido no surge debate, no se cuestionan las funcionalidades.
Hablamos de la matriz MoSCoW largo y tendido en este artículo.
Una vez que tenemos claro qué cuchillos vamos a usar es hora de empezar a cortar. Coge un pequeño listado de funcionalidades que en otro momento hayas ordenado y usa uno o dos de los frameworks propuestos para ver los resultados. Cuestiónate y aprende.
Continuará...
Foto de airfocus en Unsplash
