MVP, prototipo o prueba de concepto: qué construir primero

Cada uno pone a prueba un riesgo distinto. Esta tabla los compara uno al lado del otro.

Una prueba de concepto, o PoC, comprueba si algo es técnicamente posible. Suele ser un pequeño fragmento de código que resuelve un problema difícil e ignora todo lo demás: sin diseño, sin cuentas, sin pulir.

Por ejemplo, una startup que quiere extraer los totales de fotos de recibos escritos a mano debería comprobar primero si un modelo de IA puede leerlos con la precisión suficiente. Si no puede, ningún diseño salvará el producto.

La mayoría de los productos no necesita una PoC. Si su idea se construye con piezas probadas, como cuentas, pagos, formularios y paneles, el riesgo técnico es bajo y una PoC solo retrasa la verdadera pregunta.

El código de una PoC normalmente se desecha. Se escribió para responder rápido a una pregunta, no para sostener un producto.

Un prototipo muestra cómo funcionará el producto antes de que nadie escriba código de producción. Puede ser un conjunto de bocetos o una interfaz realista y clicable que se comporta casi como el producto real.

La guía de Nielsen Norman Group sobre prototipos de baja y alta fidelidad explica bien el equilibrio. Los bocetos sencillos son más rápidos e invitan a una crítica honesta; los prototipos de alta fidelidad muestran un comportamiento realista, algo importante cuando se prueban flujos concretos.

Un prototipo es también la mejor herramienta para poner a todos de acuerdo. AutoIntel, una herramienta B2B para el mercado alemán de coches usados, empezó como un prototipo interactivo con anuncios de ejemplo. El cliente lo recorrió con su equipo y acordaron qué campos y filtros importaban antes de presupuestar el procesamiento de datos.

Un MVP, o producto mínimo viable, es la versión más pequeña de su producto que los usuarios reales pueden usar de verdad. Tiene cuentas que funcionan, datos reales y, donde importa, pagos reales.

El objetivo es aprender, no lanzar por lanzar. En palabras de Lean Startup, un MVP se construye para «empezar el proceso de aprendizaje lo antes posible».

Un MVP puede medir lo que un prototipo no puede: si la gente vuelve y si paga. En CarPixly, un estudio fotográfico con IA para anuncios de coches, cualquiera puede registrarse y explorar el estudio gratis, y el pago llega en el momento de valor, el render. Un modelo así muestra con claridad cuántos visitantes se convierten en usuarios de pago.

La mayoría de los MVP se desarrollan en 6 a 14 semanas, según su complejidad. Nuestras guías sobre cuánto se tarda en desarrollar un MVP y cuánto cuesta un MVP SaaS dan los rangos por nivel.

Empiece por la incógnita más arriesgada. Hágase estas preguntas en orden:

• ¿Existe una posibilidad real de que no se pueda construir? Por ejemplo, depende de un modelo de IA, un sensor de hardware o una API que no ha probado. Haga una prueba de concepto.
• ¿No está claro si la gente entiende la solución o la quiere? Haga un prototipo y pruébelo con usuarios.
• ¿La gente lo entiende y lo quiere, y la pregunta abierta es si lo usará o pagará? Haga un MVP.

La mayoría de las startups se quedan en la segunda pregunta. La tecnología suele estar probada; lo que no está probado es si el producto tiene sentido para las personas a las que va dirigido.

¿No sabe cuál es el mayor riesgo de su idea? Envíenos un brief breve y le diremos por qué paso empezaríamos nosotros, y por qué.

Un prototipo solo sirve si personas reales lo prueban. La buena noticia es que necesita menos participantes de lo que creen la mayoría de los fundadores.

La investigación de Jakob Nielsen mostró que probar con 5 usuarios descubre la mayor parte de los problemas de usabilidad de un diseño. Su consejo es hacer varias rondas pequeñas en lugar de un único estudio grande.

Una ronda de prueba sencilla es así:

• Dé a cada persona una tarea realista, como «reserve un servicio para el próximo martes».
• Observe lo que hace sin ayudar ni explicar.
• Anote dónde duda, lee mal o se rinde.
• Corrija los peores problemas y pruebe la siguiente versión con personas nuevas.

Pregunte también por su comportamiento actual: cómo resuelven hoy el problema y cuánto les cuesta. Eso dice más sobre la demanda que preguntar si «usarían» su producto.

Un prototipo hecho con bocetos es una herramienta de aprendizaje y se vuelve a dibujar más adelante. Un prototipo de alta fidelidad diseñado con componentes reales es distinto: sus flujos, pantallas y sistema de diseño se convierten en el punto de partida del MVP.

Por eso diseñamos con componentes reutilizables desde la primera pantalla. Cuando el prototipo está probado y aprobado, el desarrollo empieza sobre los mismos componentes en lugar de reinterpretar una imagen.

Con una prueba de concepto ocurre lo contrario. Su código responde a una pregunta y normalmente se reescribe como es debido dentro del MVP, porque nunca se pensó para usuarios reales.

Cada paso debe terminar con una respuesta clara, no con una sensación. Escriba qué significa «éxito» antes de empezar, para que luego no se pueda reinterpretar el resultado según lo que usted esperaba.

• Una prueba de concepto tiene éxito cuando la parte difícil funciona con datos realistas, con la precisión o la velocidad que necesita el producto. «Funciona con tres archivos de prueba» no basta si los usuarios enviarán miles.
• Un prototipo tiene éxito cuando la mayoría de los usuarios de prueba completa la tarea principal sin ayuda y describe con sus propias palabras el problema que resuelve.
• Un MVP tiene éxito cuando los usuarios reales vuelven sin que se lo recuerden, o pagan, con una frecuencia que justifica la siguiente inversión.

Si un paso fracasa, también es útil. Una prueba de concepto fallida le ahorra un desarrollo caro. Un prototipo confuso le dice que cambie el flujo mientras los cambios aún son baratos.

Fije también un límite de tiempo para cada paso. Un prototipo que se sigue puliendo después de meses ha dejado de ser una prueba y se ha convertido en un producto que nadie puede usar todavía.

A veces, sí. Si ya ha validado la idea, por ejemplo con una versión manual del servicio, puede que sepa lo suficiente para ir directo al MVP.

Por ejemplo, una fundadora que lleva meses emparejando a mano a clientes con profesores particulares, con hojas de cálculo y mensajes, ya conoce los flujos y las preguntas que hace la gente. Un prototipo confirmaría sobre todo lo que ya sabe.

Saltárselo tiene sentido cuando se cumplen tres condiciones: la tecnología está probada, ha visto a personas reales pasar por el proceso y sabe qué parte del proceso debe asumir primero el software. Si falta alguna, un prototipo sigue siendo la forma más barata de averiguarlo.

Los mismos errores aparecen una y otra vez:

• Llamar MVP a un prototipo. Los clics en un prototipo muestran comprensión, no uso ni pago. No confunda una cosa con la otra.
• Pulir una prueba de concepto hasta convertirla en producto. El código escrito para responder a una sola pregunta se vuelve una base frágil para todo lo que se construye encima.
• Saltarse el prototipo. Construir un MVP antes de probar los flujos significa pagar a desarrolladores para descubrir problemas de diseño.
• Meter demasiado en el MVP. Cada función extra retrasa el momento en que descubre si el núcleo funciona.
• Probar con amigos. Quien le aprecia elogiará la idea. Pruebe con personas que tengan el problema y ningún motivo para ser amables.

¿Listo para elegir su primer paso? Cuéntenos su idea y le ayudaremos a decidir entre una prueba de concepto, un prototipo y un MVP.