Rémi Guyot, coautor de Discovery Discipline junto con Tristan Charvillat, plantea en esta tribuna las consecuencias de un discovery excesivo y desmedido por parte de algunos Product Managers y Product Designers, que pueden llevar a olvidar lo esencial que es la fase de implementación (delivery).
Recientemente, he observado un fenómeno que al principio me sorprendió, luego me divirtió y, finalmente, me preocupó. Este fenómeno es la aparición de Product Managers y Product Designers que ponen el discovery en un pedestal, en detrimento del delivery.
Al consultar a mis colegas para ver si compartían esta impresión, su respuesta no me decepcionó. Según Raphaël Bonstein, Chief Product & Technology Officer en Studapart, "la moda del discovery desvía a muchos Product Managers del delivery. Nadie quiere hacer delivery, como si fuera algo 'sucio'. A mí incluso me ha impedido contratar. Decirles a los candidatos que van a hacer especificaciones se ha vuelto tabú." Creer que el delivery es menos importante o secundario es ignorar la propia especificidad de nuestra industria. Quizás, al vivir en una burbuja, hemos olvidado que el ámbito digital es el fundamento mismo de nuestra forma de trabajar.
¿Te has preguntado por qué el ámbito digital está sistemáticamente asociado con las iteraciones y la velocidad? ¿Por qué la noción de agilidad ha surgido con tanta fuerza en el ámbito del desarrollo de software, pero no en la arquitectura de edificios, por ejemplo? La respuesta es simple: el ámbito digital permite tener un ciclo extremadamente corto entre el diseño de un producto, su distribución al público objetivo y la medición de su adopción. Este ciclo ultrarrápido permite corregir posibles errores tan rápido que es preferible lanzar algo imperfecto y corregirlo después, si es necesario, en lugar de intentar anticipar lo que sucederá. Esta especificidad, la velocidad de iteración, es el núcleo de nuestra industria. Intenta encontrar otro ámbito que permita poner tantas aproximaciones en producción. Por ejemplo, las industrias automotriz o cinematográfica serían completamente diferentes si pudieran corregir sus productos cada dos semanas basándose en datos reales de uso; desafortunadamente, sus respectivos materiales no se lo permiten.
En este contexto, debemos preguntarnos: ¿por qué necesitamos una fase de discovery en el mundo tecnológico? La respuesta se vuelve evidente cuando nos fijamos en casos extremos.
- Tomemos un primer ejemplo: imagina que no tienes permitido NINGUNA iteración. Puedes lanzar una nueva funcionalidad, pero no tendrás la oportunidad de hacerla evolucionar después. ¿Qué harías en ese caso? Tendrías la tendencia a optar por una larga fase de discovery para reducir al máximo el riesgo de cometer un error. Esta aproximación, llamada "waterfall" en el argot tecnológico, funciona, pero es terriblemente lenta.
- Ahora examinemos el ejemplo opuesto: imagina que tienes permitidas TODAS las iteraciones del mundo, a una velocidad vertiginosa. En ese caso, podrías ignorar completamente la fase de discovery y simplemente probar cada una de las variaciones posibles para identificar la mejor.
La realidad de tu entorno cotidiano probablemente se encuentre en algún punto intermedio entre los dos extremos. Necesitas hacer algo de discovery. ¿Cuánto? Lo suficiente como para eliminar los riesgos más evidentes. Ni demasiado ni demasiado poco, como la nitroglicerina.
"Querer hacer discovery sin preocuparse por el delivery es como querer elaborar nuevas recetas sin poner un pie en la cocina."
De hecho, ese es el propósito de una fase de discovery: reducir el impacto de la fase de delivery. Al final del discovery, no obtenemos certeza o pruebas, ¡sino convicción! Y es durante la fase de delivery que esta convicción se enfrenta a la realidad. Los resultados llegan, algunas hipótesis se desmoronan y otras se confirman. Comienza el aprendizaje, lo que permite una nueva fase de discovery para corregir lo necesario. Pero existe la tentación de querer aplazar indefinidamente esta fase de delivery. Renaud Vaillant, Chief Product Officer en Pyxo, lo llama "sobre-discovery", es decir, la tendencia a querer profundizar siempre más (en el problema y/o la solución) con el riesgo de no tomar decisiones ni probar nada en producción.
Las personas que ejercen como Product Managers/Designers desde hace poco tiempo tienden a sobreestimar en gran medida su capacidad (o la de su equipo) para lograr un gran impacto en una métrica determinada. Su optimismo excesivo proviene de un número insuficiente de ciclos de discovery-delivery. Por lo tanto, sin delivery, no hay ciclo de aprendizaje. Querer hacer discovery sin preocuparse por el delivery es como querer diseñar nuevas recetas sin poner un pie entrar en la cocina.
Entonces, ¿cuándo debemos detener la fase de discovery para pasar al delivery? La respuesta se reduce a una ecuación: cuando el tiempo dedicado a reducir el riesgo, multiplicado por tu tolerancia al riesgo, es mayor que el tiempo necesario para entregar la iteración.
En otras palabras:
- Cuanto menor sea el riesgo, menos discovery debes hacer.
- Cuanto mayor sea tu tolerancia al riesgo, menos discovery debes hacer.
- Cuanto mayor sea tu velocidad de entrega, menos discovery debes hacer.
¿Por qué vemos cada vez a más personas caer en el exceso de discovery? Podría haber varias causas: la creencia en el poder absoluto de los datos, un enfoque cartesiano que espera una respuesta perfecta, la costumbre de seguir un protocolo conocido, la incomodidad de tener que defender una opinión, una jerarquía que no acepta bien el fracaso, etc.
Ante el costo de la ralentización provocada por este exceso de discovery, algunas organizaciones han encontrado soluciones sencillas para evitar la contrarrestar de querer validarlo todo. Un enfoque interesante es el adoptado por Strapi, cuyo equipo de Producto ha adoptado el método descrito en Discovery Discipline antes de que el libro se publicara. Según su Chief Product Officer, Aurélien Georget, para evitar pasar más tiempo del necesario en el discovery, es necesario definir de antemano el tipo de iniciativa de que se trata:
- "Una iniciativa L significa que estamos a ciegas, por lo que realizamos un discovery exhaustivo, sacamos las linternas y exploramos.
- Una iniciativa M implica hacer un poco de discovery (aproximadamente el 50% del esfuerzo en comparación con una iniciativa L).
- Una iniciativa S se hace rápido, con muy poco discovery. Es un problema conocido y reconocido, rascamos la superficie, no es necesario reinventar la rueda."
Incluso han creado una mini-matriz con algunas preguntas para elegir si se trata de una iniciativa S, M o L.
Es evidente que la noción de asumir riesgos es fundamental para encontrar el equilibrio. Así es como debemos enfocar la fase de discovery, no como una procesión religiosa que debemos seguir sin desviarnos.
Además de la pérdida de tiempo, el exceso de rigidez en la fase de discovery - "necesito obligatoriamente tres meses a tiempo completo para entrevistar a seis personas en cada uno de los segmentos que estoy explorando" - conduce a una pérdida de credibilidad con nuestros interlocutores clave. No entienden este dogmatismo donde las supuestas mejores prácticas parecen prevalecer sobre el sentido común. Al intentar hacer demasiado, terminamos arruinando la reputación de esta fase. Demasiado discovery mata al discovery.
Existen docenas de riesgos que podríamos querer mitigar: no lograr el impacto comercial esperado, no satisfacer una necesidad del usuario, responder incorrectamente a esa necesidad, ver cómo se ignora o se malinterpreta la solución adecuada, etc. Sin embargo, estos riesgos no están relacionados entre sí. Puedes estar en lo correcto en un punto y equivocarte completamente en otro. Desactivar cada uno de estos riesgos no se logra aplicando el mismo protocolo en cada caso. Es por eso que el método FOCUSED, descrito en Discovery Discipline, permite reducir el trabajo de discovery a lo estrictamente necesario.
Además de la noción de tamaño de la iniciativa utilizada en Strapi, también puedes acelerar tu fase de discovery enfocándote en puntos específicos que merecen ser profundizados. Los entregables actúan como un diagnóstico (¿dónde están los mayores riesgos?), mientras que las actividades recomendadas permiten reducir los riesgos identificados. Cuando el entregable es claro para todos los miembros del equipo, significa que el riesgo de error es bajo y no es necesario dedicar más tiempo a ello.
Seamos claros: las fases de discovery merecen tener un proceso preciso y reiterado. Si el método FOCUSED ha encontrado eco en la comunidad, me alegro. Sin embargo, nunca se trató de jerarquizar el discovery como algo superior al delivery. Espero que continuemos creciendo colectivamente en este tema, para desarrollar nuestras prácticas sin caer en el fanatismo ciego.
