Tienes una idea y una lista que crece cada vez que la explicas: cuentas de usuario, panel, pagos, notificaciones, informes, aplicación móvil. Todo parece necesario porque cada función tiene un uso imaginable. Pero todavía no has probado si alguien necesita resolver el problema de la forma que propones.
Definir un MVP consiste en elegir la primera experiencia que permitirá aprender algo importante con usuarios reales. No es publicar una aplicación incompleta por publicar, ni reducir todas las funciones a su versión más pobre. Es construir o preparar lo necesario para comprobar una hipótesis concreta, con una operación que puedas sostener y criterios para decidir qué hacer después.
Empieza con una hipótesis que podría resultar falsa
«Queremos una plataforma para profesionales» es demasiado amplio para guiar una primera versión. ¿Qué profesionales? ¿Qué hacen ahora? ¿Dónde pierden tiempo o encuentran una dificultad? Sin esas respuestas, el equipo puede construir muchas pantallas y seguir sin saber qué está intentando demostrar.
Utiliza una frase con usuario, situación y cambio esperado. Por ejemplo: «Los responsables de pequeñas academias que reciben consultas por varios canales necesitan una lista compartida para ver quién ha respondido, y la usarán durante su trabajo semanal». Es una hipótesis de ejemplo, no una necesidad que hayamos validado. Puede fallar porque el problema no sea importante, porque otra herramienta ya lo resuelva o porque el equipo no quiera introducir datos en otro sitio.
Después escribe qué evidencia te ayudaría a evaluarla. Una opinión favorable sobre el diseño aporta menos información que observar si una persona registra consultas y vuelve para revisarlas. Si el negocio depende de una compra, el uso por sí solo tampoco prueba disposición a pagar. Conviene distinguir necesidad, uso y viabilidad comercial para no dar por validado todo a partir de una única señal.
La metodología de Lean Startup sitúa el aprendizaje y la comprobación de hipótesis en el centro del MVP. Para este trabajo práctico, la consecuencia es sencilla: cada función de la primera versión debería ayudar a comprobar la pregunta elegida o hacer posible que el servicio se utilice con suficiente fiabilidad.
Una landing, un prototipo y un MVP responden a preguntas diferentes
Una landing permite explicar una propuesta y recoger una señal de interés. Puede ayudarte a comparar mensajes o encontrar personas con las que conversar. Sin embargo, dejar un email no demuestra que alguien vaya a completar la tarea, volver a utilizar el servicio o pagar. Si tu duda principal está en la operación, una página comercial no la resolverá por sí sola.
Un prototipo permite recorrer pantallas sin construir todo el sistema. Es útil para comprobar si una persona entiende los pasos, encuentra la información y reconoce lo que debería suceder. Puede revelar que un formulario pide datos demasiado pronto o que el estado de una solicitud resulta confuso. No prueba el comportamiento real de pagos, sincronización o disponibilidad si esas funciones solo están representadas.
Un MVP ofrece una experiencia utilizable que permite observar el comportamiento relevante. Algunas tareas pueden hacerse manualmente detrás, siempre que eso forme parte de una operación definida y no se prometa una automatización inexistente. Por ejemplo, un servicio puede recibir solicitudes en una interfaz y asignarlas manualmente mientras se comprueba la necesidad. El equipo debe saber quién realiza ese trabajo y cuánto puede atender.
| Duda principal | Primer formato posible | Lo que todavía no demuestra |
|---|---|---|
| ¿Se entiende la propuesta? | Landing y conversaciones con el público previsto | Uso continuado o compra |
| ¿Se comprende el recorrido? | Prototipo con tareas observadas | Funcionamiento de la operación real |
| ¿Se utiliza para resolver la tarea? | MVP con un flujo completo | Rentabilidad a escala |
No siempre hay que recorrer los tres formatos por orden. Puedes tener evidencia suficiente sobre el mensaje y necesitar probar directamente la operación. O descubrir en las conversaciones que todavía no has definido el problema. La decisión depende de lo que ya sabes y de la incertidumbre que vale la pena reducir ahora.
Recorta alrededor de una tarea completa
Volvamos al ejemplo de la academia. Una primera versión podría permitir registrar una consulta, asignar un responsable y marcar el resultado. Eso implica una entrada, una acción y un cierre. Un panel lleno de gráficas sin una forma cómoda de mantener los datos no comprobaría la hipótesis de seguimiento compartido.
Describe el recorrido en lenguaje normal antes de convertirlo en pantallas: «La persona de recepción introduce una consulta. La coordinadora ve las pendientes y asigna a alguien. La persona asignada registra la respuesta. El equipo puede localizar consultas sin atender». Después añade los datos necesarios para que cada paso sea posible y qué roles pueden realizarlos.
Revisa las funciones propuestas con tres preguntas. ¿Sin esta función se puede completar la tarea? ¿Es necesaria para que el uso sea comprensible y fiable? ¿Ayuda a comprobar la hipótesis principal? Si no cumple ninguna, probablemente puede esperar. Un informe avanzado puede ser útil después; una forma de corregir una consulta mal introducida quizá sea necesaria desde el primer día.
Recortar tampoco significa ignorar las excepciones que aparecen continuamente. Si las consultas cambian de responsable, necesitas representar ese cambio. Si un cliente llama dos veces, el equipo debería reconocer la consulta existente. El primer alcance puede limitar tipos de usuario o canales de entrada, pero debe explicar qué ocurrirá cuando algo quede fuera. Un procedimiento manual visible es preferible a un caso que desaparece del sistema.
Prepara una lista explícita de lo aplazado. En el ejemplo podrían quedar fuera la matrícula, la facturación, las campañas automáticas y una aplicación móvil. Esa lista protege la revisión: alguien puede valorar una entrega por lo que se acordó, sin asumir que una pantalla de consultas representa toda la gestión de una academia.
Qué conviene mantener aunque la versión sea pequeña
La persona que prueba el producto necesita poder completar la tarea sin que un fallo le obligue a repetir continuamente el trabajo. Eso exige una base de calidad: datos que se guardan, errores comprensibles, acceso adecuado y una forma de recuperar la operación si algo falla. «Es un MVP» no ayuda al usuario a distinguir si una solicitud se ha registrado o no.
La autenticación y los permisos deben corresponder al contexto real. Una demo con datos ficticios puede ser pública; un piloto con información del negocio necesita limitar accesos. Define qué datos utilizarás, quién los verá y cómo se retirarán los accesos del piloto cuando termine. El detalle técnico dependerá del producto, pero la responsabilidad no puede quedar escondida detrás de una entrega rápida.
También necesitas saber quién atenderá a los primeros usuarios. Si una tarea manual forma parte del servicio, fija horarios, capacidad y qué sucede cuando llega una solicitud fuera de ese alcance. Un MVP que funciona gracias a respuestas improvisadas puede darte una señal de interés, pero no una estimación clara del esfuerzo operativo.
Por último, conserva una forma sencilla de obtener los datos del piloto. Puede ser una exportación o un informe con registros, estados y fechas. Necesitarás revisar lo sucedido y quizá decidir cambiar de solución. Si la información queda inaccesible, será difícil separar el comportamiento observado de la impresión que tiene el equipo al terminar.
Diseña el piloto antes de desarrollar las funciones
Decide qué personas necesitas observar y cómo llegarás a ellas. Los amigos pueden ayudarte a detectar errores de interfaz, pero no representan automáticamente al comprador ni al usuario previsto. Para un producto dirigido a academias, interesa que participen personas que realmente atienden o supervisan consultas, con un contexto que puedas describir.
El tamaño del piloto depende de lo que buscas aprender. Un grupo pequeño puede revelar dificultades de uso y excepciones operativas; no basta para extrapolar una tasa comercial a todo el mercado. Evita presentar un número de participantes como garantía de validación. Define qué conclusiones podrás extraer y cuáles seguirán abiertas.
Escribe las señales antes de empezar. Para la herramienta de consultas podrías observar cuántos casos reales se registran, si los responsables actualizan el resultado y si el equipo vuelve a la lista para trabajar. Anota además tareas que siguen resolviendo por fuera. Si vuelven a Excel para consultar qué falta, esa conducta aporta más información que una puntuación de satisfacción aislada.
Acuerda una revisión al terminar un periodo en el que la tarea haya ocurrido suficientes veces. No todos los negocios trabajan con la misma frecuencia. Durante el piloto recoge motivos de abandono, solicitudes de ayuda y cambios de procedimiento. Una entrevista final será más útil si puedes preguntar por un caso concreto en lugar de «¿te ha gustado la aplicación?».
Define decisiones posibles: ampliar el piloto, corregir un paso, cambiar el público previsto o detener el desarrollo. También puedes decidir que una herramienta existente resuelve el problema con menos trabajo. El aprendizaje del MVP tiene valor cuando cambia una decisión, no solo cuando justifica construir la siguiente lista de funciones.
Qué entregar a un equipo para presupuestar la primera versión
Un brief útil contiene el público, el problema, la hipótesis, el recorrido principal, los roles, los datos y el plan del piloto. Añade los límites, las tareas manuales y los criterios de aceptación. Puedes descargar una plantilla para definir tu MVP y completar estos puntos con ejemplos. Las dudas también forman parte del documento: sirven para localizar el análisis que falta.
Para los criterios de aceptación, describe comportamientos verificables. «El responsable ve solo las consultas que tiene asignadas» permite preparar una prueba. «El panel es intuitivo» necesita concretarse con tareas y usuarios. Una revisión conjunta de esos criterios ayuda a detectar diferencias antes de que aparezcan en una entrega terminada.
El presupuesto debería separar el trabajo imprescindible del que depende de una decisión posterior. También conviene conocer qué cuesta operar la versión, qué documentación recibirás y cómo se gestionan los cambios. Si aún no has decidido entre un producto existente y una solución propia, revisa primero la comparación entre SaaS y desarrollo a medida.
En Startup Studio podemos ayudarte con ideación, prototipos y desarrollo de MVPs. Para empezar no hace falta una lista cerrada de funcionalidades. Nos sirve saber quién tiene el problema, qué hace hoy y qué tendríamos que observar para considerar útil la primera versión. Con ese punto de partida se puede definir un alcance que tenga sentido probar.