Cuándo necesitas un prototipo y cuándo un producto mínimo

01 / CONTEXTO

No toda incertidumbre necesita software

Si todavía no sé quién tiene el problema, programar puede ocultar la pregunta. Si conozco el problema pero no sé si la persona entiende la solución, una pantalla dibujada puede enseñar más que una aplicación. Si quiero comprobar que puedo entregar un resultado, necesito una prueba con alcance y condiciones reales.

02 / MECANISMO

Relacionar artefacto y pregunta

Yo distinguiría cuatro niveles. Una conversación explora situación y alternativa. Un pretotipo simula la experiencia o mide una intención operativa sin construir el sistema completo. Un prototipo hace visible una interacción, flujo o resultado para observar comprensión y uso. Un producto mínimo entrega un valor real a un grupo limitado y exige definir soporte, plazo y capacidad.

La pregunta manda: ¿existe el problema? pide relatos; ¿entienden esta solución? puede pedir una maqueta; ¿pagarían por este resultado bajo estas condiciones? requiere una oferta clara o compromiso; ¿podemos repetir la entrega? requiere operar con clientes. El marco de Savoia sobre pretotipar insiste en dar con lo correcto antes de construirlo [1].

03 / EJEMPLO

Probar un servicio antes de automatizarlo

Ejemplo hipotético: quiero crear una herramienta que prepare informes para comercios. Primero entrevisto a personas sobre el último informe que hicieron. Después preparo manualmente un informe con datos que ya me comparten y observo si lo usan para decidir. Esa entrega manual puede ser un PMV del servicio si entrega valor real a un grupo limitado bajo un alcance, plazo y precio explícitos; no es un producto mínimo automatizado.

Si el resultado interesa pero las fuentes de datos cambian en cada comercio, un prototipo de interfaz no resolverá la operación. Ajusto el alcance, documento qué parte entregué y pregunto por un siguiente encargo con precio y fecha. Solo construiría automatización cuando la entrega manual revele un flujo repetible y una necesidad de reducir tiempo.

04 / APLICACIÓN

Diseñar una prueba proporcional

Escribiría la pregunta, la parte que voy a construir o simular, quién participa, qué señal observaré, qué no incluye y qué decisión tomaré. Un prototipo debe tener una tarea concreta; un pretotipo debe distinguir curiosidad de compromiso; un producto mínimo debe poder sostenerse durante la prueba.

También mediría el coste de aprender. Si tres conversaciones responden la incertidumbre, construir cien pantallas es una mala asignación. Si la pregunta es capacidad de entrega, un cliente real puede ser necesario aunque resulte más incómodo. La prueba debe incluir el límite de servicio para que la señal no dependa de una promesa imposible.

En la prueba manual del informe registraría las horas, los datos que faltaron, las correcciones y la decisión que permitió tomar. Si el resultado parece útil, intentaría repetirlo con otro comercio: el primer caso podría depender de una relación personal o de una urgencia excepcional.

05 / LÍMITES

Apariencia no es validación

Un prototipo convincente puede recibir elogios sin que nadie cambie de conducta. Una página de reserva puede medir interés inicial, pero no capacidad de pago ni entrega. Un producto mínimo no es simplemente un producto pequeño: su utilidad depende de que entregue el resultado que se quiere aprender a repetir.

06 / APRENDIZAJES

Qué me llevaría

• Nombraría primero la incertidumbre.
• Usaría la forma más barata que permita observarla.
• Separaría simular interés, entregar valor y repetir la operación.
• Definiría alcance y capacidad antes de llamar mínimo al producto.

07 / PREGUNTAS DETONANTES

Antes de construir

• ¿Qué pregunta responde este artefacto?
• ¿Qué podría aprender con una conversación o simulación?
• ¿Qué parte debe ser real para observar pago o entrega?
• ¿Qué decisión tomaré si la señal no aparece?