Construir un MVP no es recortar funcionalidades: es tomar decisiones sobre qué entra y qué queda fuera basándose en criterios concretos, no en intuición ni en listas genéricas.
Cuando hablás con founders que ya pasaron por su primer producto digital y les preguntás qué harían distinto, la respuesta más repetida no tiene que ver con tecnología, presupuesto ni equipo. Tiene que ver con decisiones: haber incluido cosas que no hacían falta en la primera versión, y haber dejado afuera otras que sí eran críticas para que el usuario obtuviera valor.
El problema no es la falta de ideas — en general sobran. El problema es la falta de criterios para decidir cuáles de esas ideas van en la primera versión y cuáles esperan. Sin criterios claros, cada funcionalidad se defiende con argumentos razonables, y el MVP termina siendo una lista de deseos con fecha de entrega.
Este artículo propone cuatro criterios para tomar esa decisión. No son una lista de funcionalidades que deben entrar o salir, sino formas de pensar cada decisión para que el resultado sea una primera versión que alguien pueda usar de verdad, obtener un resultado concreto y querer volver.
El error más común al definir un MVP es enumerar funcionalidades — "login", "dashboard", "notificaciones" — sin preguntarse primero qué resultado concreto necesita obtener el usuario. Las funcionalidades son el medio; lo que el usuario compra es el resultado.
Un ejemplo concreto: si estás construyendo una herramienta para que pequeños negocios gestionen sus pedidos, el resultado que el usuario necesita no es "ver una lista de pedidos". Es "saber qué pedidos tengo pendientes, qué debo entregar hoy y qué debo cobrar esta semana". La diferencia es enorme: la primera versión puede ser una interfaz simple con esa información, mientras que la segunda requeriría reportes, filtros, estados y métricas que son útiles pero no indispensables.
Empezar por el resultado en vez de por la funcionalidad obliga a responder una pregunta que pocos equipos se hacen al principio: ¿qué necesita ver, saber o hacer el usuario para que esta herramienta reemplace su proceso actual? Si la respuesta a esa pregunta no está clara, ninguna lista de funcionalidades va a arreglarlo.
Si tu backlog de MVP tiene más de ocho funcionalidades y ninguna descripción de qué resultado obtiene el usuario con ellas, probablemente estás diseñando un producto completo, no una primera versión.
El primer filtro es definir una persona concreta — con nombre, rol y contexto — y un solo problema que esa persona tiene hoy. No un segmento de mercado, no un perfil de usuario: una persona real o al menos un arquetipo lo suficientemente específico como para saber qué le importa y qué no.
Si tu MVP está pensado para "pequeños comercios", el filtro no está funcionando. Un pequeño comercio que vende ropa tiene necesidades distintas a uno que vende comida preparada. Si intentás que la misma primera versión le sirva a ambos, vas a terminar con una herramienta genérica que no le resuelve el problema concreto a ninguno.
La pregunta operativa acá es: ¿quién es la primera persona que va a usar esto, qué está haciendo hoy para resolver ese problema sin tu producto, y qué tendría que pasar para que deje de hacerlo de esa forma y use tu herramienta?
Elegir una sola persona y un solo problema no significa que el producto no vaya a crecer después. Significa que la primera versión tiene foco, y que las decisiones sobre qué incluir y qué dejar fuera se toman mirando a alguien concreto, no a una abstracción.
Este criterio parece obvio pero casi nunca se aplica con honestidad. La diferencia está en cómo se formula la pregunta.
La versión inútil de esta pregunta — y la que se hace con más frecuencia — es "¿esta funcionalidad es importante?". Claro que es importante. Todo lo que está en el backlog fue puesto ahí porque alguien pensó que era importante. La pregunta correcta es: "si sacamos esto de la primera versión, ¿el usuario todavía puede completar la tarea principal y obtener el resultado que busca?".
Si la respuesta es sí, la funcionalidad puede esperar. Si es no, entra en el MVP. Así de simple. Lo difícil no es el criterio, es la disciplina de aplicarlo sin excepciones.
Tomá cada funcionalidad de tu backlog y escribí en una oración qué pasaría en el flujo del usuario si esa funcionalidad no existiera. Si podés describir un camino alternativo razonable — aunque sea con más fricción —, la funcionalidad va a la segunda versión. Si el camino alternativo es inviable o rompe la experiencia por completo, entra en el MVP.
Una de las decisiones menos obvias pero más rentables al definir un MVP es identificar qué partes del producto se pueden simular con procesos manuales durante las primeras semanas, en lugar de desarrollarlas.
No todo lo que el usuario necesita ver tiene que estar construido desde el día uno. Hay funcionalidades que pueden resolverse con una llamada, un correo o una intervención puntual del equipo durante las primeras iteraciones, mientras se acumula evidencia de uso real para decidir si vale la pena automatizarlas.
Ejemplos concretos de cosas que suelen simularse sin desarrollar:
La clave es tener claro que esto es provisorio y que hay un plan para reemplazar el proceso manual cuando la evidencia lo justifique. Lo que no funciona es simular algo sin documentar cuándo y con qué criterios se va a desarrollar la versión automatizada.
Un MVP no solo entrega valor al usuario: entrega información al equipo que lo construye. Cada funcionalidad que entra en la primera versión debería ayudarte a responder al menos una de estas tres preguntas:
Si una funcionalidad no te acerca a responder ninguna de estas preguntas — es decir, si no vas a aprender nada incluyéndola —, probablemente pueda esperar. Esto aplica incluso para funcionalidades que son útiles para el usuario: si no generan aprendizaje sobre el producto o el mercado, no son prioritarias para la primera versión.
Una funcionalidad que consume dos semanas de desarrollo y no produce ninguna información nueva es un lujo que un MVP no se puede permitir. En cambio, una funcionalidad que toma tres días y te permite confirmar o descartar una hipótesis central del negocio es una de las mejores inversiones que podés hacer.
Hay categorías enteras de funcionalidades que sistemáticamente entran en los MVP sin cumplir ninguno de los criterios anteriores. No entran porque pasen los filtros: entran porque nadie las filtra.
Personalización y configuración avanzada. Que el usuario pueda cambiar colores, reorganizar paneles o configurar reglas complejas de notificación no ayuda a validar nada. Si el producto resuelve el problema, el usuario tolera la falta de personalización. Si no lo resuelve, ninguna cantidad de opciones de configuración lo va a arreglar.
Integraciones con terceros. Cada integración suma dependencia externa, tiempo de desarrollo y puntos de falla. La única integración que pertenece a un MVP es aquella sin la cual el producto no puede funcionar — por ejemplo, una pasarela de pago si el producto cobra. Todo lo demás puede esperar.
Funcionalidades para escenarios poco frecuentes. Si algo ocurre una vez por mes o le pasa al cinco por ciento de los usuarios, no pertenece a la primera versión. Construir para el borde desde el principio es la forma más rápida de inflar el alcance sin mejorar la experiencia del usuario típico.
Optimización de rendimiento más allá de lo aceptable. Un MVP puede ser más lento que la versión final. Lo que no puede ser es inusable. La diferencia entre "tarda dos segundos en cargar" y "tarda 200 milisegundos" no debería discutirse en etapa de MVP.
Múltiples formas de hacer lo mismo. Si el MVP permite completar la tarea principal de una forma que funciona, agregar atajos, accesos alternativos o métodos redundantes es una distracción. La variedad de caminos es para cuando ya sabés que el camino principal es el correcto.
La prueba definitiva de que las decisiones sobre qué incluir y qué dejar fuera fueron acertadas no está en el backlog ni en la planificación: está en lo que pasa cuando el primer usuario real usa el producto.
Si el usuario puede completar la tarea principal sin que nadie le explique nada, sin encontrar pantallas vacías ni funciones a medio construir, y al terminar entiende qué valor obtuvo, el recorte fue correcto. Si el usuario completa la tarea pero pregunta "¿y esto es todo?", el recorte fue excesivo — probablemente faltó algo indispensable para que el valor fuera perceptible. Si el usuario se pierde en funciones secundarias y nunca llega a completar la tarea principal, el recorte fue insuficiente — sobraron cosas que distraen del camino central.
No hay fórmula exacta para encontrar el punto justo en el primer intento. Pero hay una forma de acercarse: cada vez que alguien del equipo proponga incluir una funcionalidad en el MVP, pedile que responda dos cosas: qué resultado del usuario depende de esa funcionalidad, y qué hipótesis del negocio se valida con ella. Si no puede responder ambas en una oración, la funcionalidad puede esperar.
Para profundizar en cómo definir el alcance completo de un MVP sin quedarte corto ni excederte, revisá cómo definir el alcance de un MVP. Si todavía estás en una etapa anterior y necesitás confirmar si tu idea merece una primera versión, empezar por qué validar antes de desarrollar una aplicación te va a ahorrar más tiempo que cualquier criterio de recorte.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →