Como elegir el lanzamiento de producto minimo util

La planificacion de un MVP empieza con un resultado, no con una lista de funciones

La planificacion de un MVP suele fallar desde el primer paso: los equipos escriben una lista de funciones que creen que el producto necesita y luego buscan formas de recortarla. Esto produce una version reducida de todo, en lugar de una version funcional de lo unico que importa. Una pregunta inicial mas fiable es: que resultado unico, si se consigue, hace que este lanzamiento merezca la pena usarse? Todo lo demas esta al servicio de ese resultado o no forma parte del lanzamiento.

Enmarcar el lanzamiento en torno a un resultado en lugar de un conjunto de funciones tambien cambia como se evaluan los recortes mas adelante. Cuando se cuestiona una funcion, la prueba no es 'es util en general' sino 'eliminar esto impide que un usuario alcance el resultado'. Esa distincion es lo que evita que las negociaciones de alcance se conviertan en discusiones subjetivas sobre gustos.

La guia de GOV.UK sobre la fase beta plantea un punto relacionado: una beta es donde un equipo comprueba si un servicio realmente funciona para las personas, no donde se construyen todas las funciones previstas. La misma disciplina se aplica a un primer lanzamiento comercial. El objetivo de la planificacion de un MVP no es la exhaustividad, sino una respuesta decisiva sobre si el resultado central se sostiene ante usuarios reales.

Separar el resultado central de su andamiaje de apoyo

Una vez nombrado el resultado central, la mayor parte del alcance restante cae en unas pocas categorias: lo que produce el resultado, lo que hace que el resultado sea confiable (gestion de errores, accesibilidad basica, retroalimentacion clara) y lo que hace que el resultado sea comodo o conveniente pero no esencial el primer dia. Confundir la segunda y la tercera categoria es la causa mas comun del descontrol de alcance, porque las funciones de comodidad a menudo parecen necesarias para el equipo aunque un primer usuario pudiera arreglarselas sin ellas.

Una disciplina util es preguntar, para cada funcion candidata, que ocurre si falta cuando una persona real intenta completar la tarea. Si la respuesta honesta es 'recibe un error sin explicacion' o 'no puede completar la tarea en absoluto', la funcion probablemente pertenece a la categoria de confiabilidad y deberia mantenerse. Si la respuesta honesta es 'le lleva un poco mas de tiempo' o 'se ve menos pulido', normalmente puede esperar.

Esta separacion tambien protege a las interfaces accesibles de ser tratadas como un anadido posterior. La accesibilidad basica, como una navegacion por teclado utilizable, un contraste legible y mensajes de error claros, forma parte de si el resultado realmente funciona para las personas que lo necesitan, no un detalle final aplicado una vez terminado el alcance 'real'.

Usar lanzamientos pequenos y comprobables para sustituir las conjeturas

Un lanzamiento pequeno y comprobable no es simplemente un lanzamiento con menos funciones; es un lanzamiento construido para que el equipo pueda aprender algo especifico de el. Antes de construir, ayuda escribir que contaria como evidencia de que el resultado se esta cumpliendo o no. Sin ese paso, un lanzamiento pequeno sigue corriendo el riesgo de publicarse en silencio y ser juzgado solo por opinion.

La guia de priorizacion de GOV.UK plantea esto como decidir que construir a continuacion segun la evidencia de necesidad del usuario, en lugar de suposiciones internas sobre importancia. Aplicado a la planificacion de un MVP, esto significa que cada lanzamiento debe tener un alcance lo bastante ajustado como para que el equipo pueda observar, en un plazo razonable, si el resultado previsto realmente esta ocurriendo para los usuarios, en lugar de asumirlo porque la funcion existe.

Los lanzamientos pequenos tambien reducen el coste de equivocarse. Si un lanzamiento esta acotado en torno a un resultado y la evidencia muestra que no esta funcionando, el equipo ha perdido poco y sabe con precision que cambiar. Un lanzamiento construido en torno a diez funciones poco conectadas hace mucho mas dificil saber que parte fallo.

Un ejemplo practico: acotar un primer lanzamiento para una herramienta de programacion de citas

Lo siguiente es hipotetico, meramente ilustrativo, y no describe ningun producto o cliente de IVRYN. Imagina un equipo pequeno construyendo una herramienta que permite a contratistas independientes enviar a sus clientes un enlace de reserva para que estos elijan una hora sin idas y venidas de correos. El instinto del equipo, antes de recortar nada, es una lista que incluye multiples integraciones de calendario, cobro de pagos, recordatorios automatizados, programacion para varios miembros del equipo y un portal de cliente con marca propia.

Aplicando la prueba del resultado: el resultado central es 'un cliente puede elegir una hora disponible y ambas partes ven la confirmacion'. El cobro de pagos, la programacion de equipo y la marca no afectan a si ese resultado ocurre; afectan a la comodidad y a la monetizacion posterior. Una unica integracion de calendario, en lugar de varias, basta para comprobar si el mecanismo de disponibilidad y confirmacion funciona. Los recordatorios automatizados solo entran en la categoria de confiabilidad si su ausencia provocara reservas perdidas que el propio flujo central no evita ya; en este caso, un correo de confirmacion al momento de la reserva probablemente cubre ese riesgo lo suficiente para un primer lanzamiento.

El primer lanzamiento resultante: una integracion de calendario, un enlace de reserva y un correo de confirmacion. Sin pagos, sin cuentas de equipo, sin marca personalizada. El equipo ahora puede observar, en semanas, si los contratistas y sus clientes completan reservas sin confusion. Esa evidencia, no una lista de funciones mas larga, decide que se construye a continuacion.

• Nombra el unico resultado que debe lograr el lanzamiento antes de enumerar ninguna funcion
• Clasifica el alcance restante en: produce el resultado, protege la confianza en el resultado, o anade comodidad posterior
• Escribe que evidencia mostraria si el resultado esta funcionando o no antes de construir
• Trata la accesibilidad basica como parte del resultado, no como un anadido posterior
• Prefiere una integracion o un camino frente a varios, si basta para comprobar el mecanismo

Medir lo que el lanzamiento debia demostrar

Un lanzamiento acotado en torno a un unico resultado solo es util si el equipo realmente comprueba si ese resultado ocurrio. Esto significa definir, de antemano, una senal medible ligada directamente al resultado y no a la actividad general. Para el ejemplo de la programacion de citas anterior, una senal significativa es la proporcion de enlaces de reserva que terminan en una hora confirmada, no el numero de veces que se abrio el enlace o que la herramienta fue mencionada favorablemente.

Los resultados de producto medibles tambien necesitan una decision asociada, no solo un numero. Antes de que salga el lanzamiento, conviene acordar que resultado llevaria al equipo a ampliar el alcance, que resultado llevaria a cambiar de enfoque y que resultado es lo bastante ambiguo como para justificar mas tiempo antes de decidir. Sin ese acuerdo, los equipos tienden a interpretar los resultados ambiguos como confirmacion de lo que ya querian construir a continuacion.

Aqui es tambien donde la guia de priorizacion de GOV.UK resulta util mas alla del lanzamiento inicial: decidir que construir a continuacion se trata como un ejercicio continuo de sopesar la evidencia de necesidad frente al esfuerzo, no como un ejercicio de acotacion unico que termina cuando se publica la primera version.

Como trata IVRYN el alcance en su propio portafolio

IVRYN es un estudio de producto independiente con sede en Paris que mantiene un pequeno portafolio de productos separados, entre ellos Imryn, Datvero, Cascads, Reef, Flare, Sealed, Crucible CLUB y Victor Laybats, cada uno con su propio dominio, audiencia y pagina de producto. La postura editorial del estudio es documentar como se investigan, disenan, lanzan y mejoran los productos enfocados sin inflar afirmaciones, y este articulo refleja esa postura y no un informe sobre ningun resultado especifico logrado por esos productos.

Aqui no se afirma ningun estudio propio ni resultado de cliente; el razonamiento de este articulo se basa en guias publicas generales de entrega y en la preferencia declarada del estudio por un alcance claro y una utilidad medible, no en datos internos. Los lectores que evaluen su propia planificacion de MVP deberian tratar el ejemplo practico anterior como un razonamiento ilustrativo, no como evidencia de un metodo probado.

Como cada producto de IVRYN ocupa su propio alcance y audiencia, el interes practico del estudio en este tema es sencillo: un lanzamiento que intenta servir a demasiados resultados a la vez es mas dificil de evaluar honestamente, ya sea una herramienta de programacion de citas, un producto de contenido, o cualquier otra cosa.