←︎ Volver a la bitácora

La prueba más pequeña que te enseña algo

Una prueba pequeña tiene valor cuando responde una pregunta importante del proyecto. Antes de construir, decide qué necesitas aprender, qué comportamiento observarás y qué harás si el resultado contradice tu idea.

Incorporada el 7 min de lectura

Menos producto.
Una pregunta mejor.

El equipo lleva tres tardes diseñando una app. Habéis elegido colores, discutido funciones y preparado una pantalla de registro. Todo parece avanzar. Pero hay una pregunta que todavía no habéis tocado: ¿alguien necesita resolver esto lo suficiente como para cambiar lo que hace hoy?

Una prueba pequeña reduce el trabajo que haces antes de responder una duda importante. A veces necesita una pantalla. Otras, una conversación, una oferta concreta o un servicio realizado a mano. Lo pequeño no se mide solo por lo que tardas en construirlo, sino por cuánto necesitas comprometer para aprender algo útil.

La idea semilla aparece en mis apuntes sobre The Right It, de Alberto Savoia. Su propuesta de pretotipado invita a comprobar el interés por una idea antes de invertir en desarrollarla a fondo.[1] Aquí la ampliamos con una pregunta previa: ¿cuál de todas nuestras suposiciones sería más costoso descubrir tarde que era falsa?

No todas las pruebas
responden lo mismo.

Una maqueta puede ayudarte a ver si alguien entiende una secuencia. Un piloto manual puede mostrar cómo se usa un servicio. Una oferta con precio puede explorar si la persona quiere asumir ese compromiso. Cada prueba ilumina una parte del proyecto y deja otras pendientes.

Llamar a algo «prototipo», «pretotipo» o «MVP» no le da automáticamente valor. Los términos orientan: un prototipo representa aspectos de una solución; un pretotipo suele simplificarla para explorar interés o uso antes de desarrollarla; un producto mínimo viable busca permitir aprendizaje con una versión acotada. En la práctica pueden solaparse. Importa explicar qué has puesto delante de quién y qué has observado.

EJEMPLO HIPOTÉTICO · COORDINACIÓN DE EQUIPOS

Antes de programar, prueba el servicio.

Supón que quieres crear una herramienta para repartir tareas. Puedes coordinar manualmente a un equipo durante una semana: recoger sus acuerdos, hacer visibles los responsables y preguntar qué se ha completado. Ese piloto puede mostrar fricciones de uso. No demuestra que una app autónoma produzca lo mismo ni que el equipo quiera pagar.

Si la incertidumbre principal es el precio, necesitarás una oferta que lo incluya. Si es tu capacidad de prestar el servicio, necesitarás ensayar la entrega. El mismo montaje no responde todas esas preguntas.

Piloto manual de coordinación: elegir una duda, explicar el piloto, observar uso y decidir si seguir, revisar o repetir mejor. No demuestra disposición a pagar.
MAPA 01 · Una prueba, una preguntaAmpliar infografía ↗︎

La prueba también
puede estar mal diseñada.

En una nota sobre un sprint de Xcrier documenté cómo preparamos una experiencia de validación: objetivo, tareas, entrevista, materiales, captación y revisión posterior. Ensayar el recorrido nos hizo detectar cosas tan sencillas como que faltaban bolígrafos o el cargador del ordenador.[2]

Es un detalle pequeño con una implicación grande. Si una prueba falla porque no se entiende la oferta, el enlace no abre o nadie recibió la invitación, el resultado no responde limpiamente a la pregunta sobre demanda. Primero tendrás que distinguir el comportamiento del cliente de los fallos del montaje.

Después nos planteamos cambios como enfocar el producto a regalo y permitir que la persona editara sus propias fotos. No eran conclusiones definitivas sobre todo el mercado. Eran decisiones que podíamos revisar a partir de lo observado.

Define qué mirarás
antes de ver qué ocurre.

La Test Card de Strategyzer ordena cuatro elementos: supuesto, prueba, medida y umbral de éxito.[3] Puedes usar esa lógica sin rellenar ninguna plantilla. Por ejemplo: «Creemos que este equipo incorporará el seguimiento de tareas. Lo ofreceremos durante una semana y observaremos si lo usa sin recordatorios constantes».

El criterio debe encajar con la decisión. No hay un número mágico de entrevistas, clics o ventas que valide cualquier proyecto. Si eliges un umbral práctico para decidir el siguiente paso, llámalo así. Un grupo pequeño puede ayudarte a detectar un problema y orientar otra prueba; no basta para estimar cómo reaccionará todo el mercado.

Después, distingue tres desenlaces: una señal que apoya seguir explorando; una señal que aconseja revisar la hipótesis; o una prueba que no permite concluir. En ese tercer caso, explica qué impidió aprender. No necesitas celebrar todo resultado ni descartar toda idea a la primera dificultad.

La transparencia forma parte del montaje.

Una demostración no tiene que fingir que el producto ya existe. Puedes explicar que es una propuesta, un piloto manual o una versión limitada. Si solicitas un compromiso, la persona debe entender qué recibirá y qué sigue sin estar resuelto. Obtener un sí gracias a una expectativa falsa no te dice si aceptaría la oferta real.

INSIGHT

Una prueba vale por la incertidumbre que reduce y por la decisión que permite tomar.

Comprender una oferta, usar un piloto, comprar y repetir responden preguntas diferentes. Ninguna señal valida todo el negocio.
MAPA 02 · Cada señal responde una dudaAmpliar infografía ↗︎

¿Qué podríais aprender
antes de construir lo siguiente?

Mirad la próxima tarea grande del proyecto. Puede ser una web, un evento, una compra de material o una nueva función. Preguntaos qué tendría que ser cierto para que mereciera la pena. Elegid la suposición cuya respuesta cambiaría más el trabajo posterior.

Si queréis organizar un evento y no sabéis si el tema interesa a un público concreto, quizá el siguiente paso sea presentarles una propuesta clara. Si ya hay asistentes y lo que dudáis es de la experiencia, quizá necesitéis ensayar una parte. La mejor prueba dependerá del punto en el que estéis.

Cuando termine, compartid lo observado, lo que todavía no sabéis y qué vais a hacer distinto. Mantener la decisión también puede tener sentido, siempre que sepáis por qué. Aprender no exige cambiar por cambiar; exige que la realidad participe en la elección.

Aprendizajes

  • Empieza por una incertidumbre. La prueba se diseña para responder una pregunta del proyecto.
  • La señal tiene un alcance. Comprender, usar y pagar son comportamientos distintos.
  • Ensaya también el montaje. Un fallo de la prueba puede ocultar la respuesta que buscabas.
  • Fija un criterio antes. Así reduces la tentación de reinterpretar cualquier resultado como éxito.
  • Puede haber un resultado inconcluso. Reconocerlo permite mejorar la prueba sin inventar certezas.
  • Explica lo que existe. Un piloto transparente produce un compromiso mejor entendido.

Preguntas detonantes

Lleva a tu próxima conversación de equipo la pregunta que más conecte con lo que estáis viviendo.

  1. ¿Qué estamos construyendo sin saber todavía si hace falta?
  2. ¿Cuál sería la suposición más cara de descubrir tarde que era falsa?
  3. ¿Nuestra prueba podría producir un resultado que nos hiciera cambiar de opinión?
  4. ¿Qué no podríamos concluir aunque el resultado fuera favorable?
  5. ¿Qué parte de la experiencia podría fallar por nuestro montaje y no por falta de interés?

Para seguir aprendiendo

PARA ENTENDER LA BASE

La propuesta de valor se descubre. No se inventa.

Explica qué valor esperas aportar para elegir qué necesitas comprobar primero.

Leer bitácora →︎
PARA SEGUIR AVANZANDO

Un elogio, una prueba y una compra no dicen lo mismo

Distingue lo que demuestra un elogio, una prueba de uso o una compra.

Leer bitácora →︎
PARA AMPLIAR LA MIRADA

Un sprint sirve para responder una pregunta

Conoce una forma de concentrar prototipado y aprendizaje cuando la pregunta requiere un sprint.

Leer bitácora →︎

Cómo se ha elaborado esta bitácora

Esta bitácora parte de los apuntes y reflexiones reales que Iván guardó en su Notion personal durante sus cuatro años en LEINN. Ese archivo se ha organizado en una base de 521 notas de conocimiento. Cada entrada toma un concepto de esa base y lo amplía con referencias, explicaciones e infografías para convertirlo en un recurso de aprendizaje.

Fuentes

  1. Alberto Savoia · Pretotyping. ↗︎

    Punto de partida de los apuntes sobre The Right It. Consultada la presentación pública del método; no se afirma lectura del libro completo.

  2. Iván Carrillo · Cómo ejecutar una estrategia de validación para mi idea de proyecto.

    Original de Notion: planificación de la prueba de Xcrier, ensayo de materiales y decisiones posteriores. No aporta tamaño de muestra ni una evaluación independiente. No se equipara al caso de hoteles. Original conservado en el archivo personal; no disponible públicamente.

  3. Alex Osterwalder · Validate Your Ideas with the Test Card. ↗︎

    Fuente primaria para explicitar supuesto, prueba, medida y criterio. Los ejemplos de esta bitácora son hipotéticos y no reproducen un caso de Strategyzer.

Datos de la entrada
Incorporada el
Última revisión
17 de septiembre de 2026 · Versión 1
Primera lectura recomendada
1.º de LEINN · Changemaker
Relectura
Cuando cambien el cliente, la oferta o la complejidad del proyecto
Idioma
Español
Apoyo de IA
OpenAI Codex · texto y edición
ImageGen · infografías
Modelo
Familia GPT-6; variante exacta no expuesta por el cliente
Estado
Publicada en everleinner.com