Cómo definir el MVP de una app antes de pedir presupuesto

Empieza con una frase que describa quién utilizará el producto, en qué situación y qué necesita terminar. Por ejemplo: una persona que coordina actividades quiere confirmar qué participantes asistirán a la siguiente sesión. Ese ejemplo delimita una tarea. Decir que quieres una plataforma de gestión abre muchas posibilidades sin indicar cuál debe resolverse primero.

Documenta cómo se hace hoy ese trabajo. Quizá haya una conversación, una hoja compartida y varias confirmaciones manuales. Identifica dónde se pierde información o hay que repetir pasos. Si aún no lo sabes, observa el proceso con futuros usuarios antes de convertirlo en pantallas. Una primera versión definida sobre una rutina real se puede revisar con preguntas mucho más concretas.

Describe el inicio, las acciones y el resultado de la tarea. En el ejemplo de asistencia, alguien crea la sesión, invita a los participantes, recoge las respuestas y consulta el resultado. Decide cómo accede cada persona y qué información puede ver. Ese recorrido permite detectar dependencias que una lista de pantallas suele ocultar.

Incluye las situaciones que hacen utilizable el recorrido: una invitación que no llega, una respuesta duplicada o una sesión cancelada. La primera versión puede tener pocos recorridos, pero los previstos deben poder completarse con sus errores habituales. Deja explícito qué hará el producto y qué tendrá que resolver el equipo durante la prueba.

Anota qué incertidumbre justifica construir la primera versión. Puede ser comprobar si la gente completa una tarea sin ayuda, si la información recogida es suficiente o si un cambio encaja con la forma de trabajar del equipo. Asóciala a una observación: dónde se detienen los usuarios, qué datos faltan o qué casos requieren una intervención manual.

Define antes de la prueba quién revisará los resultados y qué decisión se tomará después. Una muestra reducida ayuda a detectar dificultades, con límites sobre lo que se puede concluir. Evita interpretar cualquier uso inicial como una validación de todo el negocio. La prueba debe responder a la pregunta que has formulado y dejar identificadas las que siguen abiertas.

Clasifica cada función según su relación con la tarea principal. Algunas son necesarias para que el recorrido funcione; otras mejoran su comodidad. Un informe descargable puede esperar si la persona ya puede consultar el dato que necesita. En cambio, identificar quién ha confirmado la asistencia puede formar parte del resultado mínimo acordado.

Algunas operaciones pueden resolverse manualmente durante una prueba acotada, siempre que haya una persona responsable y un procedimiento claro. Escribe cuánto trabajo genera esa decisión y cuándo habrá que revisarla. Aplazar una función no elimina la necesidad que resuelve: puede trasladarla al equipo. Esa carga debe ser visible cuando se aprueba el alcance del MVP.

Distingue lo que necesita una conversación con usuarios, un prototipo de pantallas o una prueba técnica. Si no se entiende el recorrido, puedes revisar el diseño antes de desarrollarlo. Si la duda es si un sistema externo proporciona la información necesaria, hay que comprobar el acceso y la respuesta. Cada tipo de duda requiere una evidencia distinta.

Recoge las condiciones de la prueba: dispositivos, datos que se utilizarán, participantes y canal para comunicar incidencias. Acuerda quién preparará contenidos y quién atenderá a los usuarios. Un producto pequeño también necesita operación. Si nadie puede revisar las incidencias o corregir la información, las conclusiones de la prueba pueden quedar condicionadas por esa falta de soporte.

El documento del MVP puede ser breve, pero debe permitir que diseño, desarrollo y negocio entiendan el mismo encargo. Adjunta el recorrido, ejemplos de contenido y las dudas pendientes. Pide que la propuesta identifique las hipótesis que todavía necesita confirmar, y revisa estos puntos antes de aprobarla:

• Usuario principal y situación de uso definidos.
• Recorrido que se podrá completar de principio a fin.
• Funciones incluidas, aplazadas y operaciones manuales asignadas.
• Pregunta que responderá la prueba y forma de observarla.
• Criterios de revisión, responsables y siguiente decisión.