Cómo desarrollar un MVP

Cómo desarrollar un MVP partiendo de un problema concreto

Si estás pensando cómo desarrollar un MVP, empieza por el problema y no por la lista de funcionalidades. Un producto mínimo viable es una versión real y acotada que genera evidencia interpretable para una decisión concreta. Esa decisión puede ser seguir invirtiendo en un flujo de trabajo, acotar el público o parar. Si no puedes formular el problema en una sola frase, indicando quién lo tiene y cuánto le cuesta hoy, cualquier desarrollo será una apuesta a ciegas.

IVRYN es un estudio de París que gestiona varios productos, cada uno enfocado en su propio público. Ese contexto da forma a los consejos de este artículo. Se inclina por un alcance reducido, una utilidad que se pueda medir y una automatización de la que se pueda rendir cuentas. Este artículo aplica esas preferencias al trabajo con MVP. No es el informe de un estudio ni describe resultados de ningún producto concreto.

Decide qué pregunta responde tu MVP

Distingue tres tipos de trabajo antes de definir el alcance. Una prueba de concepto valida una única suposición técnica concreta, por ejemplo si una integración se comporta como se espera, si un cálculo cabe dentro de una restricción o cómo se gestiona un caso de fallo específico. No demuestra demanda, usabilidad ni preparación operativa. Un prototipo comprueba si la gente entiende una interacción. Un MVP se publica de verdad, para que un grupo acotado de usuarios reales pueda usarlo y tú puedas recoger evidencia. La guía de IVRYN sobre prototipos, MVP y pruebas de concepto explica estas diferencias, y confundirlas es la forma en que los equipos acaban respondiendo a la pregunta equivocada.

Sé prudente con lo que significa esa evidencia. La guía señala que un MVP desplegado no demuestra por sí solo un uso regular, adopción, ingresos ni encaje producto-mercado. Por eso, anota la decisión que informa la versión, la hipótesis que la sustenta y el resultado que te llevaría en un sentido u otro. Por ejemplo: "Si las agencias invitadas envían dos informes semanales consecutivos a través de la herramienta, automatizaremos la tercera fuente de datos; si no, las entrevistaremos antes de construir nada más". Una frase así te dice qué construir, a quién invitar y qué medir.

Acota la versión más pequeña que siga siendo segura de publicar

Traza el único recorrido que sigue un usuario desde que llega con el problema hasta que se va con él resuelto. Cada pantalla, integración o ajuste que no esté en ese recorrido es candidato a eliminarse. Los pasos manuales entre bastidores son aceptables al principio, siempre que seas honesto sobre lo que cuestan y sobre sus limitaciones.

Recortar el alcance tiene un límite, eso sí. Como un MVP se publica y no solo se muestra en una demo, su perímetro puede incluir autenticación, autorización, privacidad, accesibilidad, gestión de errores, monitorización y recuperación siempre que el contexto lo exija. "Mínimo" se aplica a las funcionalidades, no a las salvaguardas importantes. Si personas reales inician sesión, comparten datos o dependen del resultado, las protecciones asociadas forman parte del mínimo.

Planifica versiones lo bastante pequeñas como para poder evaluarlas. Una versión que agrupa cinco cambios hace imposible saber cuál importó. Un único cambio relevante por versión, cada uno con un efecto esperado, mantiene la evidencia legible.

• Escribe el problema, la decisión y la hipótesis en una sola página.
• Enumera los pasos del recorrido principal del usuario y elimina todo lo demás.
• Indica qué pasos están automatizados y cuáles se gestionan manualmente.
• Enumera las salvaguardas que exige tu contexto y mantenlas dentro del alcance.
• Define qué significa "terminado" para cada versión antes de construirla.

Crea interfaces accesibles desde la primera versión

La accesibilidad no es un retoque para más adelante. Si las personas que usan teclado, lector de pantalla o tienen baja visión no pueden completar el recorrido principal, tu MVP subestimará la necesidad real y te dará una señal distorsionada. Además, corregir la estructura después sale más caro que hacerlo bien mientras la interfaz todavía es pequeña.

Céntrate en lo básico a lo largo del recorrido principal: encabezados y etiquetas semánticos, estados de foco visibles, contraste suficiente, errores de formulario explicados con texto y flujos que no dependan del color ni de movimientos precisos del puntero. Compruébalo a mano en cada versión, porque los verificadores automáticos ayudan pero no lo detectan todo.

Comprobaciones de fiabilidad: mide resultados y verifica la versión

Mide si el problema quedó resuelto, no solo si la gente hizo clic. Las métricas útiles de un MVP se vinculan con la decisión: tareas completadas, tiempo comparado con el método anterior o uso repetido cuando la necesidad vuelve a aparecer. El número de registros rara vez indica si el producto es útil.

La fiabilidad depende tanto de la disciplina en las publicaciones como de las métricas. La página pública de metodología de IVRYN describe cómo trata la evidencia de producto, y aquí se aplica el mismo espíritu: decide de antemano qué vas a contar, registra lo que cambió y no afirmes más de lo que los datos permiten. Una compilación local no es una versión publicada con éxito. Hasta que no se haya comprobado el endpoint público, solo sabes que el producto funciona en tu propia máquina, así que da un despliegue por terminado únicamente después de esa comprobación.

• ¿Se fijaron los criterios de éxito y de fracaso antes del lanzamiento?
• ¿Cada métrica está vinculada al recorrido principal y no a la actividad general?
• ¿El flujo principal muestra estados de error claros y ofrece una forma de recuperarse?
• ¿La recogida de datos se limita a lo que la funcionalidad realmente necesita?
• ¿Están anotadas las dependencias de terceros, con sus restricciones de disponibilidad y coste?
• ¿Se comprobó el endpoint público tras el despliegue, y no solo la compilación local?
• ¿Existe un registro de lo que cambió en cada versión y de qué versión está en producción?
• ¿Se informa a los usuarios de los pasos manuales cuando es relevante?
• ¿Se comprobó la accesibilidad del recorrido principal en esta versión?

Ejemplo práctico (hipotético): una herramienta de informes para agencias pequeñas

Solo es un ejemplo, no un proyecto real. Un equipo de dos personas cree que las agencias de marketing pequeñas dedican horas cada semana a montar a mano los informes para sus clientes. La decisión que deben tomar es si automatizar una tercera fuente de datos o replantear el público. El MVP admite una plantilla de informe y dos integraciones, y la tercera fuente se gestiona manualmente. Como las agencias conectarán cuentas de clientes, se mantienen dentro del alcance el inicio de sesión, el acceso limitado a los informes de cada agencia y un error claro con opción de reintentar cuando falla una integración.

La primera versión se envía a un pequeño grupo de agencias invitadas tras comprobar el uso con teclado y lector de pantalla y verificar la dirección en producción. La señal acordada es si la mayoría envía dos informes semanales consecutivos a través de la herramienta. Eso informa la decisión sobre la automatización; no demuestra adopción. La segunda versión cambia una sola cosa, la automatización de la fuente manual, para que su efecto pueda interpretarse por separado. Si las agencias abandonan tras un solo informe, el equipo habla con ellas antes de añadir funcionalidades, porque quizá lo que falla sea el problema o el público y no el desarrollo.