Cómo definir un MVP: qué incluir en la v1

Aprender a definir un MVP es, sobre todo, un ejercicio de resta. La mayoría de los fundadores y responsables de producto llegan con una lista de funciones que describe el producto que quieren dentro de dos años y luego preguntan cómo meterla en un primer lanzamiento. El resultado es un desarrollo que tarda mucho más de lo previsto y que aun así no responde a la única pregunta que importa: ¿alguien quiere esto?

Definimos el alcance de MVPs para empresas y fundadores con regularidad, y el patrón se repite. Los equipos que lanzan no son los que tienen las ideas más pequeñas, sino los que tienen la línea de corte más nítida: una lista escrita y sencilla de lo que entra y lo que queda fuera.

Este artículo muestra cómo hacemos ese corte, incluida la lista de fase 2 que proponemos con más frecuencia y los puntos que nos negamos a sacar de una primera versión.

Empieza por el problema, no por la lista de funciones

Escribe el problema en una sola frase

Usa una fórmula: «[Usuario específico] hoy no puede [hacer una tarea concreta] porque [obstáculo], lo que le cuesta [tiempo, dinero o riesgo]». Si no puedes completarla sin jerga ni un segundo párrafo, el alcance todavía no está definido: es una lista de deseos con fecha límite. Reescríbela hasta que un colega sin perfil técnico pueda repetirla correctamente.

Elige al usuario que más sufre el problema

Un MVP atiende a un solo tipo de usuario mediante una acción central. Cuando un proyecto tiene dos tipos de usuario, pregunta cuál pagará primero o se quejará más fuerte si el problema sigue sin resolverse. Construye para ese. El segundo tipo de usuario pasa a ser un punto de la fase 2, no un compromiso de la fase 1.

Nombra la acción que cuenta como éxito

Elige la única acción que demuestra que el producto funciona: un trabajo reservado, una factura enviada, un pedido pagado. Todo lo que hay en la pantalla debería apoyarla; lo que no lo haga es candidato a eliminarse.

La línea de corte: imprescindible, deseable y más adelante

Cada función recibe una de tres etiquetas. Clasificamos con tres preguntas.

1. Sin esta función, ¿el usuario puede completar igualmente la acción central?

Si la respuesta es sí, pasa a «más adelante». Las funciones que mejoran una experiencia pero no la hacen posible son de fase 2 por definición. Solo esta pregunta elimina la mayor parte de la lista.

2. ¿Depende de datos, permisos o una cuenta que todavía no tenemos?

Todo lo que depende de un tercero —la revisión de un proveedor de pagos, la aprobación de una tienda de aplicaciones, una clave de API, el sistema del propio cliente— arrastra tiempos de espera que no puedes comprimir escribiendo código más rápido. Decide si es posible lanzar sin eso.

3. ¿Podría una persona hacerlo a mano para los primeros usuarios?

Reportes manuales, una importación desde una hoja de cálculo, una bandeja de soporte que dispara una tarea interna: todas son formas válidas de entregar el resultado mientras el software se mantiene pequeño. Automatiza la segunda versión, no la primera.

Define «terminado» antes de que alguien construya

Anota cómo se ve un MVP terminado en términos observables: un usuario real se registra, completa la acción central en el sistema en vivo con datos reales y recibe una confirmación. Acuerden esa frase por escrito; más adelante resuelve la discusión del «casi está listo». Nuestro servicio de desarrollo de MVP se define justo en torno a ese criterio.

Una lista concreta de lo que espera a la fase 2

Lo que posponemos con más frecuencia

• Paneles de administración y analítica más allá de una exportación a CSV
• Roles y permisos más allá de una división simple entre propietario y miembro
• Pantallas de configuración, temas, marca blanca y personalización de marca
• Varios idiomas y monedas
• Una app móvil nativa cuando una aplicación web responsiva hace el trabajo
• Tours de incorporación autogestionados, referidos, cupones y lógica de afiliados
• Integraciones con herramientas que no son donde ya viven los datos
• Funciones de IA que no son la razón por la que el usuario está ahí

Lo que no recortamos

• Autenticación bien hecha, incluida la recuperación de cuenta
• Un modelo de datos pensado para la siguiente versión, no solo para esta pantalla
• Pagos y comprobantes, si el negocio cobra dinero
• Consentimiento, control de acceso y una forma de eliminar una cuenta y sus datos
• Registro de errores y un canal para escuchar a los usuarios

Decisiones de alcance que ahorran desarrollo

Diseña el modelo de datos para la v2, construye la interfaz para la v1

Las pantallas son baratas de añadir y cambiar. Los datos no. Un esquema que ya contempla los campos y las relaciones que esperas después te permite crecer sin una migración que toque datos en producción. Este es el único punto que, a propósito, nos negamos a recortar.

Empieza los puntos lentos en la primera semana

El dominio y el correo, la verificación del proveedor de pagos, las cuentas de las tiendas de aplicaciones, el acceso a APIs de terceros y las páginas legales consumen tiempo que no puedes recuperar después. Lístalos el primer día y asigna un responsable a cada uno.

Trata un prototipo como una demo de alcance, no como una base

Si tu equipo ya armó un prototipo en herramientas como Lovable, Bolt, Cursor, Replit o v0, tienes algo útil: muestra el flujo que quieres. Pero todavía no es un producto. La autenticación, las reglas de datos, la seguridad y el despliegue aún requieren decisiones; cubrimos esa brecha en aplicaciones hechas con vibe coding.

Preguntas frecuentes

¿Cuántas funciones debe tener un MVP?

No hay una cifra correcta. La prueba es si un usuario real puede completar una acción central, de principio a fin, sin rodeos. Si el alcance necesita un diagrama para explicarse, probablemente son dos lanzamientos.

¿Podemos lanzar con trabajo manual detrás?

Sí, y lo recomendamos para reportes, incorporación y casos límite. El trabajo manual solo se vuelve un problema cuando esconde una regla que el software debería decidir; documenta esa regla antes de automatizarla.

¿Cuánto tarda en construirse un MVP?

Depende de cuánto tenga que aprobar otra persona. Las integraciones, la verificación de pagos, la revisión de la tienda de aplicaciones y el acceso a los datos del cliente suelen marcar el calendario más que el código. Definimos el trabajo y las dependencias en conjunto antes de poner una fecha.

¿Listo para reducir tu alcance a algo que puedas lanzar? Cuéntanos qué necesitas construir y revisaremos tu lista de funciones, separaremos la primera versión de la fase 2 y la convertiremos en un plan.