Más allá del Dual Track: Una nueva metodología que podría transformar la forma de hacer producto digital
Más allá del Dual Track: Una nueva metodología que podría transformar la forma de hacer producto digital
Itamar Gilad, en su libro "guiado por evidencias", está desafiando el paradigma del Dual Track, y lo está sustituyendo por un nuevo proceso que permite de forma sistemática validar nuestras ideas
TL;DR
A principios de la semana compartí leí un artículo de Marty Cagan que se llama “Más allá de Lean y Agile”.
En este artículo el famoso gurú del producto digital desafiaba la metodología “Lean y Agile” y planteaba una alternativa en donde el proceso de descubrimiento se convertía en la piedra fundamental para poder validar hipótesis.
Esta validación de hipótesis se hacía en una fase que Marty Cagan denominó “Discovery” (descubrimiento) y que quedaba desligada de una segunda fase llamada “Delivery” (entrega).
Esto quería decir que habría 2 backlogs.
En el primero se harían experimentos de validación de nuestras ideas, y en el segundo se llevarían a cabo los desarrollos de dichas ideas.
El sprint de descubrimiento iba adelantado en un sprint al de desarrollo, por lo que la “maquinaria de hacer software” ahora correría en dos velocidades y con dos motores diferenciados.
Esta metodología ha traído muchas ventajas para la industria de creación de producto, pero a medida que se pone en práctica también empiezan a traslucir deficiencias y mejoras que se podrían llevar a cabo en Dual Track.
En el libro de Itamar Gilad estos problemas se exponen de forma clara, y se plantean soluciones que empiezan a revolver estos problemas, y se divide en 4 pasos
Objetivos: Sigue la misma metodología de OKRs y métrica North Star
Ideas: Se evaluan ideas en base al impacto en las métricas, la facilidad de implementación, y sobre todo la confianza que tenemos de éxito de la idea
Pasos: Se van tomando pasos de discovery hasta que las mejores ideas ganan
Tareas: Se definen las acciones a tomar para poder avanzar en cada uno de los pasos definidos
Yo veo una gran mejora en esta propuesta de framework de creación de producto cuando la comparo con el framework de Dual Track, pero sólo el tiempo dirá si esto es así o no.
Porqué el Dual Track está roto y cómo podemos arreglarlo
La razón principal por la que se empieza a usar Dual Track en las empresas es por la consistente petición de las personas en dirección de funcionalidades que estaban seguros que sus ideas serían exitosas y estas ideas se llevan directamente a desarrollo.
La solución a este problema fue el “dual track”.
El objetivo principal de la fase de discovery era validar las hipótesis y usabilidad de la funcionalidad o producto que se quería construir.
El problema es que este paso se convirtió en un “trámite” para poder definir la usabilidad del producto antes de desarrollo.
El problema es que el dual track no deja mucho margen de error. Si haces un discovery de una funcionalidad, el siguiente paso es construir o no construir.
Para los equipos de producto es complicado pedir una segunda ronda de discovery, y si se solicita, tampoco saben bien hasta cuando tendrá que durar el discovery para validar de forma fehaciente las hipótesis de producto.
La alternativa al Dual Track: GIST
La alternativa al modelo de Dual Track que plantea Itamar Gilad en su libro “Evidence Guided” se llama GIST.
Las siglas GIST definen los siguientes pasos que hay que seguir en la creación de producto:
Goals (Objetivos): Este primer paso es el mismo que se plantea en la metodología de OKRs. Esto es, que objetivos queremos obtener y que resultados clave conseguiremos con dichos objetivos
Ideas: Este paso buscamos formas de poder validar nuestras hipótesis. Estas ideas no sólo vienen de dirección o del equipo de producto, sino que pueden venir desde cualquier persona en la organización
Pasos: Este tercer paso de la metodología GIST define a alto nivel que bloques de trabajo podríamos hacer para validar y evidenciar nuestras hipótesis
Tareas: En este último paso se define todas las tareas dentro de los pasos que se necesitan para completar cada uno de los pasos
Con esta descripción a alto nivel todavía no vemos la diferencia de la metodología de Dual Track, pero a medida que vayamos profundizando veremos cómo la validación con evidencias es mucho más robusta que la metodología de Dual Track.
Objetivos (Goals)
Como decíamos antes, los objetivos en la metodología GIST no cambian mucho de cómo se plantean en otras metodologías de producto, pero si vale la pena repasar dichas metodologías
OKRs
Los OKRs definen los objetivos de un equipo en tres partes:
Objetivo: Es una declaración corta que describe el resultado deseado, el cambio que nos gustaría llevar a cabo . Un ejemplo podría ser “los creadores de contenido pueden completar la creación de los contenidos de forma independiente”
Resultados Clave: Aquí definiremos 2 a 5 resultados clave que queramos medir. En este caso podemos segmentar el objetivo en varios resultados. Un ejemplo de resultado podría ser "“Más de un 50% de creadores de contenidos empieza el proceso de creación en menos de una semana del onboarding de producto”
Contexto (opcional): El contexto, que es opcional, explica de forma más clara porqué se debería perseguir este objetivo, y porqué es importante para la organización
Métrica “North Star”
La métrica “North Star” es un número concreto que define el valor más importante que el producto puede dar al mercado. El creador de esta métricca, Sean Ellis, la define cómo un producto deja su “marca de valor” en el mundo.
Ejemplos:
WhatsApp: Número de mensajes por mes
YouTube: Número de minutos vistos por mes
AirBnB: Número de reservas por mes
Amplitude: Número de usuarios que aprenden por semana
Ideas
La mayoría de las ideas no son buenas
“Si quieres tener buenas idaes debes de generar muchas ideas". La mayoría de tus ideas no darán resultados y lo que tendrás que aprender es cuales son las que tienes que tirar a la basura y cuales tienes que seguir persiguiendo”
- Linus Pauling
La propuesta de la metodología GIST es simple y a la vez poderosa, y una vez vista tiene todo el sentido del mundo.
Estos son los dos cambios que Itamar propone en el proceso de discovery:
Generar más y mejores ideas a traves de procesos de discovery: Este es el core de discovery, y hay cientos de técnicas para llevar a cabo procesos de discovery.
Usar evidencia para seleccionar las mejores ideas que desarrollaremos: Este es el paso más innovador de la metodología GIST
Usar evidencia para elegir ideas
En los procesos de discovery acabamos el discovery y nos quedamos en un limbo en donde no sabemos si desarrollar la funcionalidad o no.
Estos procesos de discovery compiten con otros procesos de discovery que hemos llevado en el pasado, y esto no deja definir un framework para poder seleccionar las mejores ideas.
El problema que soluciona el paso de las ideas de la metodología GIST es poder medir la validez de los procesos de discovery que hemos llevado a cabo, priorizandolos para poder seleccionar los mejores.
La metodología, sobre la que profundizaremos más adelante en este post, sigue el siguiente ciclo de toma de decisiones
Evaluación usando puntiación ICE
La puntuación ICE es uno de los pasos más importantes dentro de la metodología GIST.
La evaluación ICE está basada en 3 puntuaciones:
Impacto (Impact): Esta métrica define cuanto podría mejorar la métrica North Star, y este impacto depende de cómo el producto define esta métrica. Cuanto más alto sea este valor, más impacto generará nuestro producto o funcionalidad en la métrica de North Star
Confidencia (Confidence): Confidencia está 100% enfocado en medir el nivel de validez que tenemos de que el proceso de discovery ha sido exitoso y funcionará para nuestros usuarios. Cuanto más alta sea esta puntuación más confianza tendremos de que la funcionalidad conseguirá darnos los resultados que esperamos.
Facilidad (Ease): Define cuanto tiempo nos llevará desarrollar toda la solución. Cuanto más alta sea esta puntuación más sencillo será para el equipo poder llevar a producción los cambios que se quieren implementar
Imaginemos varias ideas que tenemos en el pipeline. Cada una tendrá una puntuación concreta y se comparará con el resto a través de una tabla como la que se muestra abajo.
Mi foco ahora será en el el segundo paso, que es la medición de la confianza. Si quieres profundizar en los otros 2 pasos te recomiendo que compres el libro de Itamar.
Midiendo la confianza
Para mi este paso ha sido el que ha hecho que se me encienda la bombilla porque crea una medición concreta para evaluar nuestros procesos de discovery.
Itamar ha creado un “medidor de confianza” en donde se puntua el grado de validez de los procesos de discovery.
Esto nos permite evaluar de forma dinámica una misma funcionalidad en base a la validez del proceso de discovery, y que una misma funcionalidad pueda cambiar de posición dentro del proceso de discovery en base a los experimentos validados que hayamos llevado a cabo.
Debajo podemos encontrar el peso de cada uno de los niveles de confianza, que comentaré por encima
Casi cero (de 0 a 0.1): Esta puntuación suele se da cuando se tiene una idea sin validar. Quizás aumenta mínimamente si la idea está alineada con la estrategia de la empresa. En muchas empresas este es el punto de partida si no hay procesos de discovery definidos.
Evaluaciones básicas (de 0.1 a 0.5): En este punto se hacen evaluaciones de expertos y se pueden hacer estimaciones financieras básicas y se dibujan modelos de negocio que validan la idea
Evidencia en anécdotas de soporte o ventas (de 0.5 a 1): Se tienen verbatim de equipos de equipos de soporte o ventas, que traen peticiones concretas de clientes que apuntan a un problema concreto en el producto
Evidencia en datos del mercado (de 1 a 3): Se hacen encuestas y se mira a la competencia para validar que el mercado tiene esta necesidad
Evidencia con usuarios y MVPs(de 3 a 5): Hemos validado con usuarios, ya sea con testeando mocks dinámicos con usuarios o lanzamientos de MVPs en producción que muestran evidencias claras de éxito
Datos de lanzamiento (de 5 a 10): Tenemos suficientes datos que validan de forma fehaciente nuestras hipótesis después del lanzamiento de una parte mínima de la funcionalidad
Este proceso de evaluación de la confianza que tenemos en nuestros experimentos de discovery nos permitirán re-priorizar algunas funcionalidades que en principio no parecían ser malas ideas y con el tiempo empiezan a tener más peso dentro del proceso de discovery.
Pasos
Este tercer paso en la metodología GIST nos permite hacer iteraciones en los procesos de discovery de las ideas que tenemos en curso, para poder ir validando nuestras hipótesis de forma progresiva, y aumentando la confianza que tenemos en que la idea que estamos validando será exitosa.
Quizás una idea con una puntuación alta y a medida que vamos avanzando en nuestros procesos de discovery estas puntuaciones van cambiando.
El caso explorado en el libro compara un dashboard con un chatbot. Lo que yo destacaría del estado inicial, y lo que pone en foco la metodología GIST la poca confianza que tenemos en ambas soluciones.
Si bien al principio el Dashboard tiene mayor puntuación a medida que llevamos a cabo más procesos de discovery ambas ideas van cambiando de puntuación ICE, pero sobre todo vamos mejorando la confianza que tenemos en ambas soluciones para poder elegir de forma más objetiva la idea que mejores resultados nos dará al llevar a producción.
La importancia de los pasos
Este punto, combinando con la medición de la confianza es para mi la clave que hace que la metodología de GIST pueda con el tiempo sustituir (o complementar) a la metodología de Dual Track.
El foco principal es llevar a cabo pasos para tener mayor evidencia de que la idea que estamos probando funcionará
Tareas
Sin entrar en muchos detalles, el último paso de la metodología GIST son las tareas que se tienen que llevar a cabo para poder ejecutar un paso.
A diferencia de la metodología de Scrum o Kanban, aquí no sólo se incluyen los desarrollos que se tengan que llevar a cabo, sino cualquier tarea necesaria.
Esto podría incluir hacer un formulario para hacer una encuesta, hacer el diseño de una landing o llevar a cabo tests de usuario.
El punto aquí es que el equipo se enfoque en llevar a cabo las acciones para llevar a cabo un paso concreto que nos permita validar una idea.
Retos de la metodología
Incorporar la nueva metodología en equipos de producto
Como cualquier nuevo framework de trabajo, hay que probarlo y en muchas ocasiones estos cambios en la forma de trabajar conllevan frustración y varios intentos hasta que aprendemos y nos acostumbramos a los nuevos rituales para hacer producto.
Sin un buen acompañamiento y sin un sponsor fuerte dentro de una organización de producto es poco probable que esta metdología de hacer producto funcione
La metodología invita a que cualquier rol apoye en cualquier tarea
En la metodología se invita a que cualquier rol pueda llevar a cabo cualquier tarea y que el foco 100% sea ejecutar los pasos para obtener la validación que el equipo necesita para poder confirmar que conseguiremos los objetivos que queremos obtener.
En startups este tipo de forma de trabajar es muy normal y suele darse de forma natural ya que la supervivencia de la empresa está en juego.
En empresas con más empleados y estructuras este tipo de forma de trabajar no es tan natural y puede que genere fricciones en roles que quieren enfocarse en sus fortalezas.
Se genera mucha deuda técnica que luego se tiene que limpiar
Debido al gran foco en el discovery y en la validación de hipótesis de la forma más rápida posible, en esta nueva metodología se genera mucha deuda técnica, ya que el objetivo no es sacar a producción sino aprender y buscar validación de nuestras hipótesis.
Esto querrá decir que mucho del trabajo realizado tendrá que “tirarse a la basura” porque se hizo con el foco de validar y con la posibilidad de que esa validación nos indicara que la hipótesis no es válida.
Un ejemplo claro es un desarrollo de “Mago de Oz”. Esto es, un desarrollo en donde la lógica de negocio está realizada por un ser humano que procesa de forma “magica” los procesos de negocio manualmente. Si el experimento funciona, la “magia manual” tendrá que tirarse a la basura y se tendrá que desarrollar una lógica de negocio más robusta que sirva para cientos o miles de usuarios
Madurez en el uso de datos para validar ideas
A veces hay que dejar ir nuestras propias creencias sobre las ideas que funcionarán y las que no funcionarán.
El punto aquí es poder mirar de forma objetiva los datos para aceptar la evidencia que dichos datos nos dicen, y aceptar el veredicto de los datos.
Pero para poder medir de forma objetiva los datos necesitamos primero definir las métricas de dichos datos y luego tener una buena infraestructura de datos que nos permitan llevar a cabo dichas validaciones.
Esta madurez es esencial para poder tomar decisiones basadas en evidencias y no siempre se tiene una infraestructura cuficientemente robusta o suficiente conocimiento a la hora de medir
Conclusiones
El dual track a ayudado mucho en el mundo de producto para poder validar nuestras ideas con experimentos antes de llevar dichos experimentos a producción.
En la metodología GIST se nos invita a validar de forma iterativa los procesos de discovery para poder tener más evidencias que validen que nuestras ideas funcionarán para nuestro negocio y nuestros clientes.
Como cualquier framework nuevo, sólo el tiempo dirá si esta metodología es un avance en la forma de hacer producto digital y si se convertirá en el nuevo estándar de creación de producto.
Personalmente creo que las ventajas son mayores que los inconvenientes, y que la única forma de validar esta hipótesis es tirarse a la piscina para poder validar la metodología en el día a día de nuestros productos digitales.
Si quieres seguir profundizando en esta metodología, te recomiendo que compres el libro de Itamar Gilad, que podrás encontrar en el siguiente enlace: