El 16 y 17 de junio de 2018, Marty Cagan, autor de Inspired, uno de los libros más importantes del mundo en la creación de productos, vino a Brasil para impartir el curso How to create products customers love, en la ciudad de São Paulo. Durante el curso, nos alegró mucho ver que el contenido que brindamos en los formaciones de K21 está perfectamente alineado con lo que piensan las grandes mentes de productos, pero nos molestó la brecha entre la mentalidad de producto y el día a día de las empresas en Brasil.
Por ello, decidimos compartir aquí algunos consejos de Cagan para hacer que la vida de todos fuera más feliz y productiva.
Si no estás practicando la Agilidad ...
"… necesitamos conversar". Así fue como Cagan abrió su formación, sorprendido al ver que algunas personas en la sala no levantaran la mano cuando preguntó quién usaba alguna forma de Agilidad en su trabajo. Además, al igual que Jeff Sutherland el pasado año y Ken Schwaber en 2013, se pronunció en contra del uso de SAFe en las empresas, afirmando categóricamente que "¡SAFe es un veneno!".
Un modelo desordenado de Scrum
Es muy común encontrar el escenario de empresas que comenzaron a adoptar la Agilidad, pero están haciendo entregas como esta:
Cuando Cagan diseñó este slide, supe que me esperaba un fin de semana divertido. En la parte superior dice "Las Causas Raíz del Fracaso", luego vemos algo muy común: primero la alta dirección tiene las ideas, a seguir un plan de negocios, un Roadmap, después los requisitos: diseñamos, construimos, probamos y cargamos para producir. Solo basta poner sprints en la parte de construcción y listo, esto es Agilidad.
Por lo contrario, esta es la garantía de que hemos perdido toda la adaptabilidad necesaria para encontrar el market fit (cómo encaja tu producto en el mercado). Es un modelo de ejecución que no brinda ninguna apertura a ningún aprendizaje, tampoco brinda pruebas de hipótesis y (in)validación de los supuestos que tuvimos a lo largo del proceso. Como una guinda sobre el helado, no estamos haciendo entregas frecuentes ni impulsando nada hacia el valor. Es un desastre.
A partir de ese momento, Cagan comenzó a dedicar todo su esfuerzo a romper cada uno de los paradigmas que habíamos creado mientras nos acostumbrábamos al statu quo del día a día en una empresa cuya mentalidad ágil aún no está madura.
Los planes de negocios no funcionan
La razón por la que los planes de negocios son atractivos es que dan una falsa sensación de seguridad. Introduces información sobre cuánto costará tu producto, cuánto pretendes vender y cuál es el retorno esperado, y lo usas para aprobar la financiación del producto.
El problema es que toda esta información es ficticia. No sabemos cuánto tiempo llevará desarrollar un producto porque, para empezar, no tenemos garantía de que el mercado lo reciba con agrado. Tampoco estamos seguros de cómo se construirá este producto que imaginamos, mucho menos si resuelve un problema lo suficientemente doloroso como para que la gente pague por él. Y, precisamente por eso, no podemos garantizar cuánto venderemos y cuál es la rentabilidad esperada. De hecho, estamos pidiendo financiación en primer lugar precisamente para poder descubrir toda esta información que ponemos como certezas en el plan de negocio.
Sin embargo, nos exigirán respuesta de lo que escribimos en el plan como si fuera una bola de cristal USB.
Roadmap como causa del fracaso
Sin escrúpulos, Cagan dijo que te arrepentirás de al menos la mitad de las ideas que pusiste en tu Roadmap. Pero cuando presentamos un Roadmap, estamos simplificando el camino hacia un producto exitoso, y vendiendo una idea de linealidad que no refleja la realidad. Al mirar un Roadmap, los patrocinadores creen que estamos ante la mera ejecución de una lista de features, cuando en realidad se parece más a un nido de polillas borrachas que nadie quiere desplegar. Las exigencias comienzan a surgir por encima de la ejecución y no del aprendizaje, y ¡felicidades! Tenemos otro producto que nadie usará en el mercado.
En la misma línea, Cagan reforzó que lo más arriesgado que podemos hacer es no correr riesgos, porque sabemos que las cosas cambiarán y hay mucho que no podemos asegurar. Si este es un hecho, debemos comenzar a (in)validar las hipótesis y mitigar estos riesgos lo antes posible, en lugar de evitarlos.
Tipos de riesgo
Una vez que hayas comenzado a (in)validar las hipótesis, es importante que tengas en cuenta que existen diferentes tipos de riesgo que debemos abordar al administrar un producto:
- riesgos de valor: ¿Estamos resolviendo un problema real? ¿Esta forma de solucionar el problema aporta valor a mi cliente? ¿Pagará la gente por esto?
- riesgos de usabilidad: ¿Mi cliente podrá usar el producto?
- riesgos de viabilidad técnica: ¿Es posible construir este producto?
- riesgos de viabilidad empresarial: ¿Podemos asumir los riesgos de este producto?
Y una buena manera de monitorear mejor estos riesgos es a través de un MVP.
¿MVP es un producto?
Otra buena bofetada en la cara: Cagan dijo, acertadamente, que es común ver empresas que construyen MVP de 4 meses. Un MVP de 4 meses no es un MVP, porque un MVP es un prototipo, no un producto. Las empresas han utilizado el término MVP para crear productos mal fabricados y no probados, lo cual está lejos del objetivo de esta técnica.
La razón de ser del MVP radica en (in)validar hipótesis y -según Cagan- es común que una Startup tenga al menos 100 iteraciones de su producto antes de encontrar el mercado adecuado. Ahora considera que una Startup generalmente tiene dinero para sobrevivir durante 1 o 2 años, e imagínate que tarde 4 meses para llevar su producto a manos del primer cliente, solo para luego recopilar feedback y hacer la primera iteración (de 100). Es probable que esta Startup llevara 20 años hasta encontrar el mercado adecuado, y casi ninguna tiene el suficiente dinero para sostenerse durante tanto tiempo.
Con este problema en mente, un equipo debe hacer de 15 a 30 iteraciones en un prototipo durante una semana, siempre (in)validando hipótesis y aprendiendo rápido. Asimismo, un error común de los equipos es esperar hasta la Revisión para mostrar por primera vez el producto a las partes interesadas. La propuesta es hacer esta validación antes, mostrando el prototipo y recogiendo constantemente feedback.
Dual-track Scrum
Cagan también se refirió un poco al término acuñado por Jeff Patton, explicando que puedes trabajar en dos franjas: una para el descubrimiento y la otra para la entrega. La franja de descubrimiento es donde "finges" y la de entrega es donde "lo logras". Esta es una referencia a la expresión fake it till you make it, que significa "finge hasta que lo logres". En la banda de descubrimiento, el equipo se centra en la creación de prototipos y (in)validación de hipótesis. Paralelamente, el equipo construye lo que ha validado en sus hipótesis. No debería haber un momento en el que el equipo solo valide o construya, porque siempre necesitamos aprender y siempre entregar un producto que funcione para el cliente. Sin embargo, para un problema particularmente difícil, es factible hacer un design sprint, donde el equipo se concentra en probar e iterar posibles soluciones a ese problema.
El papel del equipo de desarrollo
“Si estás utilizando a tus desarrolladores para escribir códigos, solo obtendrás la mitad de sus valores”. Resolver un problema difícil requiere que varias mentes piensen juntas. Si excluimos a los desarrolladores del intenso ciclo de creación de prototipos y pruebas, estaremos privando a nuestro producto de pruebas de viabilidad, además de tener diferentes puntos de vista basados en las tendencias tecnológicas. A veces pensamos en algo muy complejo, como un bolígrafo que puede escribir en gravedad 0, el desarrollador se acerca y pregunta "¿Por qué no usamos un lápiz?"
Ya que estamos hablando de la participación del equipo, Cagan señala que los mejores equipos no están formados por estrellas. Son pequeños, duraderos, multidisciplinares, miran el alcance completo, preferentemente ubicados en el mismo lugar y trabajan orientados a resultados. Sobre todo, incluso si cada miembro del equipo tiene un conocimiento más profundo de una disciplina, una buena señal de equipos fantásticos es que no puedes distinguir fácilmente quién es el gerente de productos, el diseñador o el desarrollador. Todos trabajan en una colaboración tan intensa que estos roles son solo conocimiento agregado al conjunto.
OKR
Para dar visibilidad a la organización y garantizar que todos los equipos estén remando en la misma dirección, Cagan propuso reemplazar el infame Roadmap con OKR. De esta forma, los equipos y la organización se vuelven menos orientados al volumen de entrega y más orientados a los resultados del negocio. Además, los OKR son una excelente manera de ayudar al equipo a enfocarse en (in)validar y construir lo que realmente aporta valor, y decir no a todas las otras demandas que recibe de la organización. (Ver más sobre OKR haciendo clic en este enlace).
Escalada
Sobre trabajar con Agilidad a escala, Cagan hizo referencia a Airbnb y la lógica de que, para escalar, primero hay que hacer cosas que no escalen. De nada sirve buscar un modelo que se ajuste a todos los escenarios y organizaciones. Como dijo Peter Drucker, la cultura se come a la estrategia en el desayuno, por lo que si aplicamos cualquier tipo de definición organizacional sin que surja de la interacción entre las personas, la aceptación es baja y la estructura se convierte en un problema en lugar de una solución.
Con esto, Cagan sugiere que se desarrolle un liderazgo fuerte dentro de los siguientes roles:
- Líderes de Productos: a cargo de la visión, estrategia y estructura del equipo
- Líderes de diseño: cuidando el lenguaje y los estándares de diseño
- Líderes de Diseño: a cargo del lenguaje y estándares de diseño
- Líderes de Ingeniería: a cargo de la arquitectura y estructura del equipo
- Líderes de Datos: a cargo de las herramientas de análisis de datos y el lenguaje de los KPI (indicadores clave de rendimiento)
- Líderes en Entrega: a cargo de las fechas y dependencias de entrega
En última instancia, estos líderes servirán como evangelizadores de mejores prácticas. ¿Pero no es lo que todos estamos haciendo?
Fueron dos días intensos repletos de contenido, pero el propósito de esta publicación es solo brindarte una idea de cómo podemos pensar mejor en un producto y evitar las trampas más comunes. Si quieres saber más, ¡sigue nuestro blog!
¿Quieres saber más sobre este tema?
¿Quieres aprender a crear productos exitosos? Inscríbete en nuestra formación de Certified Scrum Product Owner (CSPO)
Mira también otras publicaciones relacionadas con este tema haciendo clic en los enlaces a continuación:
Métricas de efectividad del producto en Métricas: Cómo medir la Agilidad de tu equipo.
