El framework de priorización definitivo sólo tiene una pregunta
¿Es esto lo más importante que deberíamos estar haciendo? De cómo respondiendo a esta cuestión podemos solucionar el 80% de nuestras decisiones estratégicas.
Hace unos meses, un amigo ingeniero me preguntaba cómo podía convencer a su Product Manager para que le dejara invertir algo de su tiempo en mejorar una interfaz del backoffice de su producto. Aparentemente, era uno de los más usados, pero la usabilidad dejaba mucho que desear y se podía arreglar fácilmente. Mi respuesta fue algo parecido a, ¿es esto lo más importante que deberías estar haciendo?
Últimamente me veo mucho recurriendo a esa pregunta, a la que empiezo a considerar uno de mis principales frameworks de priorización. Creo firmemente que cuando respondes a esa cuestión, el 80% de tus decisiones estratégicas se resuelven prácticamente solas.
Y es que hacerlo nos obliga a hacer sacrificios. Sólo puede haber una iniciativa que sea la más importante. No dos ni tres. Una. Tomar este tipo de decisiones es la base de la planificación estratégica.
Volviendo al ejemplo de mi amigo. Podríamos pensar que mejorar esa interfaz es fruta madura. Vemos un problema evidente, aparentemente fácil de resolver, y pensamos que está al alcance de nuestra mano poder solucionarlo rápidamente. Imaginemos que decidimos hacerlo.
Idealmente deberíamos prototipar los cambios y validarlos con nuestros usuarios, pero claro, probablemente nos cueste más hacerlo que implementarlos directamente. Y esta mejora es tan clara que no hace falta perder más tiempo con ello. Además, si lo hiciéramos, ya no sería fruta madura.
Al igual que no validamos, tampoco vamos a hacer demostraciones y entrenar al personal que utiliza a diario esa interfaz. Vamos a simplificar tanto el flujo que no necesitará ninguna explicación. Si nos tocase invertir ese tiempo haciéndolo, tampoco sería fruta madura.
Así pues, después de pasar una semana programando, llega el día en el que la desplegamos a producción nuestra mejora. El teléfono empieza a sonar. No para bien. Resulta que los usuarios no entienden por qué ha cambiado. ¿Es un fallo? ¿Se han equivocado de url? ¿Dónde está la página antigua? Llega el momento de dar explicaciones.
Los que usan a diario la herramienta se indignan. — ¿Cómo cambiáis algo así sin consultarnos? Nuestro día a día depende de esto. Necesito hacer algo ahora y no sé cómo hacerlo. Dejadlo todo como estaba por favor. — Las quejas van escalando por la cadena de mando.
Te indignas tú también. Has puesto tiempo y esfuerzo en mejorar una interfaz que claramente va tener un impacto positivo en la productividad de toda la empresa, pero lo único que recibes son reproches. Empiezas a mirar ofertas de trabajo en LinkedIn.
¿Qué hubiera ocurrido si antes de empezar nos hubiéramos planteado, es esto lo más importante que debería estar haciendo? De todos los retos que tiene tu empresa, de todas las oportunidades y problemas que tienen tus clientes, ¿es este realmente el que más duele?
Lo que aparentemente puede parecer fruta madura, también puede ser una trampa mortal. Una vez inicias un camino, no sabes lo que te vas a encontrar después de cada paso que des.
No caigas en la trampa. Cuestiónate siempre si realmente vale la pena recoger todas esas frutas al borde del camino o es mejor a tu destino final cuanto antes. Cuando llegues seguirán estando ahí, nadie te las va a quitar. Pero si no llegas…
The essence of strategy is choosing what not to do. — Michael Porter.
Críticas al artículo
Si rechazas este tipo de iniciativas el equipo se puede desmotivar
Una de las críticas que se podría hacer al artículo es que si un ingeniero propone una de estas iniciativas y la rechazas, puede llegar a desmotivarse.
Mi punto sería, ¿por que el ingeniero no está pensando en lo más importante? Gran parte de nuestro trabajo como Product Managers consiste en motivar al equipo sobre el problema que estamos tratando de resolver en el momento.
Esto es casi una labor de venta. Tienes que conseguir que el equipo entienda por qué es importante lo que están haciendo. Para hacerlo tienes que:
Demostrar que conoces íntimamente al usuario y el problema que quieres resolver.
Explicar claramente como resolver ese problema impactará sobre la empresa.
Involucrar al equipo cuánto antes en el discovery del problema para que vaya calando.
Si consigues tener al equipo motivado, será raro que un ingeniero acuda a ti con una idea que no apoye el objetivo que perseguís.
¿Cómo averiguo qué es lo más importante?
En Twitter me llegó este comentario. No tengo una buena respuesta para ello porque creo que lo más importante suele ser también evidente.
La empresa generalmente tendrá unos objetivos y nosotros como Product Managers estaremos al tanto de una serie de problemas que pueden impactar sobre los mismos Lo habitual será priorizar aquellos que tengan más impacto siempre que el tiempo nos de para ello.
A muy alto nivel, podemos utilizar técnicas como Impact Mapping para estimar el impacto que esperamos conseguir con cada iniciativa. Después podemos aplicar las medidas de esfuerzo e incertidumbre para valorar cada una de ellas y tratar de priorizar. Algo así hace Intercom con su método RICE.
Pero lo dicho. En mi experiencia generalmente lo más importante, lo que más impacto tiene, suele ser evidente. Lo normal sería centrarse en eso, trabajando con el equipo para reducir incertidumbre y esfuerzo de forma que podamos ir avanzando sobre ello.
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes utilizar estos enlaces para compartirlo directamente en Twitter o LinkedIn y así me ayudarás a que esta lista de correo llegue a más gente. ¡Gracias de antemano!