Qué es un MVP en el desarrollo de producto

Qué es exactamente un MVP en el desarrollo de producto

Un MVP, o producto mínimo viable, es la versión más pequeña de un producto que permite a un equipo poner a prueba una hipótesis concreta sobre el uso real con usuarios reales, y reunir evidencia antes de comprometerse con una construcción mayor. La palabra 'mínimo' se refiere al alcance, no a la calidad: un MVP tiene que funcionar, tiene que ser usable y tiene que resolver el problema al que se dirige. La palabra 'viable' es la parte más difícil, porque significa que el lanzamiento tiene que ser lo suficientemente completo como para que alguien pueda depender realmente de él para la tarea en cuestión, no solo mirarlo.

La confusión en torno a este término suele venir de tratar MVP como sinónimo de 'borrador' o 'demo'. Una demo puede simularse; un MVP no, porque su propósito entero es producir una señal fiable sobre si la gente lo usa y si cambia su comportamiento. Si el lanzamiento es demasiado limitado como para generar esa señal, en realidad no ha funcionado como un MVP, se le llamara como se le llamara internamente.

También ayuda ser preciso sobre qué no es un MVP. No es un prototipo, que existe sobre todo para probar una idea de diseño internamente o con un grupo pequeño antes de comprometerse realmente a construir algo. No es una prueba de concepto, que existe para responder a una pregunta técnica concreta, como si una integración o un enfoque es siquiera viable. Un MVP se sitúa después de ambos: asume que la idea merece intentarse y que el enfoque técnico es plausible, y pone a prueba si el producto se gana un uso real.

Las decisiones que un MVP pretende reducir en riesgo

La pregunta del lector que merece la pena examinar no es 'qué es un MVP' en abstracto, sino qué decisiones protege realmente de un error. Tres decisiones aparecen una y otra vez. La primera es el alcance: si el problema que el equipo cree estar resolviendo es el problema que la gente realmente tiene, con el nivel de prioridad asumido. La segunda es el encaje en el flujo de trabajo: si la solución propuesta encaja en cómo la gente ya trabaja, o exige un cambio de comportamiento que no va a producirse. La tercera es la secuencia de inversión: si tiene sentido construir la siguiente capa de funcionalidades, o si la capa actual ya revela un callejón sin salida.

Ninguna de estas preguntas puede responderla por sí sola un documento de especificación, una discusión de hoja de ruta o una maqueta bien diseñada. Requieren observar qué ocurre cuando el producto se usa realmente para la tarea prevista, aunque sea de forma limitada. Ese es el riesgo concreto que un MVP reduce: el riesgo de invertir meses de esfuerzo de ingeniería y diseño en una hipótesis que estaba equivocada desde el principio, descubierta solo después de haber pagado ya el coste.

Un MVP no reduce en riesgo todo. Dice poco sobre la retención a largo plazo, la tolerancia al precio, o cómo se comportará un producto a una escala significativamente mayor o bajo uso adversarial. Eso requiere otro tipo de evidencia, reunida más tarde, normalmente a partir de un producto que ya ha superado el listón más básico de resultar útil para un primer grupo de usuarios reales.

Un ejemplo hipotético desarrollado: decidir qué entra en el primer lanzamiento

Consideremos un ejemplo hipotético. Un equipo pequeño cree que los gestores de operaciones freelance pierden tiempo conciliando facturas de clientes entre hojas de cálculo e hilos de correo, y quiere construir una herramienta para ello. Antes de escribir una sola línea de código para una plataforma completa, el equipo necesita decidir cómo es la versión mínima viable de esta idea, y qué debe conseguir para contar como una prueba real y no como un lanzamiento desperdiciado.

En este supuesto hipotético, el equipo podría decidir lanzar una herramienta de propósito único que solo importe facturas desde un formato de exportación habitual y señale discrepancias frente a un total proporcionado por el cliente, sin paneles, sin cuentas de usuario más allá de un único inicio de sesión y sin soporte para varias divisas en el lanzamiento. La prueba no es si la herramienta luce pulida. La prueba es si los gestores de operaciones realmente suben facturas reales, vuelven a hacerlo la semana siguiente y dejan de mantener la hoja de cálculo manual que usaban antes.

Este ejemplo es meramente ilustrativo, no una afirmación sobre ningún producto que IVRYN haya construido u observado. Su propósito es mostrar cómo una definición de MVP se traduce en una decisión de alcance concreta: qué recortar, qué conservar y qué evidencia contaría como una respuesta genuina y no como una cómoda.

Una ayuda sencilla para este tipo de conversación sobre alcance es plantear tres preguntas sobre cualquier funcionalidad propuesta para el primer lanzamiento: si eliminarla hace imposible completar la tarea central, si mantenerla retrasa el lanzamiento más allá del punto en que la retroalimentación sigue siendo barata de aprovechar, y si su ausencia haría deshonesta la prueba al ocultar el problema real. Una funcionalidad que falla la primera pregunta y supera las otras dos suele poder recortarse del MVP con seguridad.

• ¿Eliminar esta funcionalidad hace imposible completar la tarea central?
• ¿Mantenerla retrasa el lanzamiento más allá del punto en que la retroalimentación sigue siendo barata de aprovechar?
• ¿Su ausencia haría deshonesta la prueba al ocultar el problema real que se está evaluando?

Principios que mantienen honesto a un MVP

La claridad del problema va primero. Un MVP construido sobre un enunciado de problema vago o cambiante producirá resultados ambiguos por muy bien que se ejecute, porque el equipo no sabrá qué significa realmente una señal positiva o negativa. Escribir el enunciado del problema en una sola frase, y comprobar que cada funcionalidad del lanzamiento se corresponde con él, es una forma barata de detectar el descontrol de alcance antes de que empiece.

Los lanzamientos pequeños y comprobables importan más que el minimalismo técnico por sí mismo. El objetivo no es construir lo menos posible; es construir lo más pequeño que produzca una respuesta fiable a una pregunta concreta. A veces eso exige más funcionalidad de la que un equipo espera, en particular cuando la tarea que se está probando tiene una complejidad mínima natural, como manejar pagos o programación de citas.

Las interfaces accesibles son fáciles de despriorizar bajo presión de tiempo, pero un MVP difícil de usar generará una retroalimentación ruidosa o engañosa, ya que la gente luchará con la interfaz en lugar de reaccionar a la idea subyacente. Mantener la interfaz sencilla, aunque sea visualmente plana, protege la integridad de la propia prueba.

Los resultados de producto medibles cierran el ciclo. Antes del lanzamiento, conviene decidir de antemano qué evidencia contaría como una señal para continuar, ajustar o detener, en lugar de decidirlo a posteriori según qué cifras parezcan más favorables. Se trata menos de elegir una única métrica y más de ser honesto con el equipo sobre qué cambiaría realmente el plan.

Cómo el contexto público del producto de IVRYN acota este consejo

IVRYN es un estudio de producto independiente con sede en París que mantiene una cartera de productos separados, entre ellos Imryn, Datvero, Cascads, Reef, Flare, Sealed, Crucible CLUB y Victor Laybats, cada uno con su propio dominio, audiencia y página de producto. Este artículo refleja la postura editorial general del estudio de documentar cómo se investigan, diseñan, lanzan y mejoran los productos enfocados sin inflar afirmaciones, en lugar de describir los resultados del lanzamiento de un producto concreto.

El consejo aquí está acotado en consecuencia. No se cita ningún estudio propio, prueba de usuario o medición de resultados de un producto de IVRYN, y no debe inferirse ninguno a partir de este artículo. El ejemplo hipotético desarrollado más arriba es un ejemplo didáctico, no un caso de estudio, y los principios se ofrecen como un marco general coherente con la preferencia declarada del estudio por el alcance claro, la utilidad medible y la automatización responsable, no como evidencia extraída de un lanzamiento concreto.

Para quienes quieran una comparación más estructurada de los términos que se usan de forma laxa en torno a 'MVP', incluyendo en qué se diferencia de un prototipo o de una prueba de concepto en alcance y propósito, esa distinción se trata por separado y se referencia en las fuentes de evidencia de este artículo en lugar de repetirse aquí en su totalidad.

Una breve checklist antes de llamar a algo un MVP

Los equipos a menudo discrepan sobre si un lanzamiento dado califica como un MVP real o es en realidad una demo interna inacabada etiquetada con optimismo. Una checklist breve puede resolver la mayoría de estos desacuerdos sin un largo debate.

Si un lanzamiento cumple la mayoría de los puntos siguientes, razonablemente puede llamarse un MVP. Si incumple varios, probablemente esté más cerca de un prototipo o de una prueba de concepto interna, y debería tratarse como tal, con expectativas distintas sobre lo que sus resultados realmente significan.

• Resuelve un problema claramente enunciado para un tipo de usuario concreto, no una visión general.
• Una persona real ajena al equipo puede completar la tarea central sin que se le guíe paso a paso.
• El equipo ha decidido de antemano qué resultado contaría como señal para continuar o para detenerse.
• Excluye funcionalidades que estarían bien tener pero que no son necesarias para probar la hipótesis central.
• El equipo está preparado para actuar según resultados negativos, no solo positivos.