Ejemplo hipotético: esta startup nace de tres personas que quieren resolver un único problema: preparar el registro de entregas de pequeños talleres gráficos. El caso ilustrativo es ficticio y no describe una empresa real. MEE lo utiliza para recorrer decisiones sobre especialización, aprendizaje y ampliación, con dudas y límites que deben permanecer visibles.
Caso ilustrativo: escoger un problema antes de construir
En el escenario imaginado, el equipo evita empezar por una plataforma para «gestionar cualquier negocio». Delimita una tarea: reunir la información necesaria para saber qué pedido debe entregarse, a quién y con qué especificaciones. Todavía no sabe si otros talleres consideran importante ese problema ni cómo lo resuelven. Esa incertidumbre forma parte del punto de partida.
La primera propuesta consiste en observar un proceso con permiso y utilizar después datos ficticios para preparar una muestra. El equipo separa lo que ha entendido de lo que supone. Que una persona explique un problema no significa que quiera comprar una solución digital. El caso conserva esa diferencia antes de introducir un producto.
Repartir especialidades sin perder la visión del conjunto
Una persona prepara las conversaciones y describe el proceso; otra construye una versión de prueba; la tercera revisa instrucciones y posibles errores de uso. Son funciones creadas para este ejercicio. No representan un reparto universal entre fundadores ni prueban que un equipo de tres personas tenga más posibilidades de éxito que otro.
El acuerdo de trabajo identifica quién decide el alcance, quién revisa cada entrega y qué información necesitan compartir. Si una función depende de otra, lo anotan. La especialización no permite suponer que las piezas encajarán solas. En el escenario, una prueba común consiste en recorrer el registro de principio a fin y comprobar qué instrucciones faltan.
Qué tomamos de Eric Ries
La presentación oficial de The Lean Startup explica el ciclo de construir, medir y aprender, y plantea revisar si conviene perseverar o cambiar una hipótesis. MEE toma esa pregunta como referencia para el caso. La página no se utiliza como prueba de que seguir el método garantice ventas, crecimiento o supervivencia de una empresa.
La versión inicial se limita a un registro de prueba. Antes de enseñarla, el equipo escribe qué quiere observar: si la persona puede identificar una entrega pendiente y señalar información incompleta. No pretende validar toda una empresa con esa operación. El resultado debería permitir revisar esa tarea concreta y preparar la siguiente pregunta.
Primeros clientes y aprendizaje dentro de la ficción
Para continuar el relato, suponemos que un taller ficticio acepta un piloto delimitado. Las condiciones del escenario incluyen una duración acordada, datos autorizados y revisión del procedimiento anterior antes de sustituirlo. El equipo identifica errores y preguntas. No inventamos nombres de clientes, testimonios, ingresos o tasas de crecimiento para presentar la experiencia como evidencia real.
Durante ese piloto imaginado, una instrucción resulta ambigua: no distingue una entrega preparada de una efectuada. El equipo modifica la explicación y vuelve a probarla. Puede describir qué cambió y bajo qué condiciones se revisó. Eso no demuestra todavía que la solución funcione en todos los talleres o que pueda atender más usuarios sin apoyo.
En lugar de sumar funciones por cada comentario recibido, conservan una lista con tres apartados: problema observado, propuesta pendiente y cambio probado. Preguntan qué tarea resolvería cada petición y qué recursos exigiría. También registran el trabajo manual que ha hecho posible el piloto. Ocultarlo daría una imagen incompleta de la capacidad del producto.
El salto a una capacidad vecina
La continuación ficticia incorpora otra pregunta del mismo taller: preparar un aviso cuando una entrega esté lista. El equipo identifica qué información ya tiene y qué cambia al enviar una comunicación. Debe estudiar destinatario, contenido, autorización, fallos y posibilidad de corregir el aviso. Compartir un registro no resuelve automáticamente esas cuestiones.
Antes de ampliar, comparan esa función con mejorar las instrucciones actuales. La nueva posibilidad queda como una prueba separada. Si el relato avanza hacia más talleres, conserva condiciones de atención y soporte explícitas; no presenta el crecimiento como un premio inevitable por empezar en pequeño. La capacidad vecina puede mostrar costes distintos de los previstos.
Argumento contrario: el primer problema puede estar mal elegido
Ries incluye cambiar de hipótesis en su ciclo de aprendizaje. Esa posibilidad cuestiona una lectura rígida del caso: concentrarse durante mucho tiempo en un problema no demuestra que merezca resolverse de la manera elegida. Si la prueba no aporta la información necesaria, toca revisar la pregunta, el procedimiento o la propuesta, en lugar de llamar «constancia» a cualquier repetición.
Una comparación para reconocer los límites
Ejemplo hipotético: otro equipo empieza ofreciendo una herramienta para reservar clases individuales. Al conversar con quienes organizan las sesiones, descubre que el problema principal es comunicar cambios de horario. En este escenario, mantener exactamente el primer producto podría desatender lo observado. El equipo tendría que decidir qué hipótesis revisar antes de añadir funciones o asumir nuevos compromisos.
La comparación no determina qué equipo tendría mejores resultados. Expone dos decisiones: delimitar una tarea para poder estudiarla y conservar la posibilidad de cambiarla. Para trasladarlo a tu actividad, evita copiar la aplicación imaginada. Escribe tu problema, qué sabes de él y qué observación podría hacerte modificar la propuesta.
La lectura de MEE
El valor del caso está en las preguntas que permite revisar. Describe un problema, reparte responsabilidades y prepara una muestra con una comprobación definida. Registra el apoyo que exige y lo que no has verificado. Antes de crecer, explica qué capacidad compartiría la siguiente oferta y qué compromisos nuevos introduciría. Conserva abierta la opción de mantener o corregir el alcance.
Preguntas frecuentes
¿Esta startup existió y tuvo clientes reales?
No. Es un caso ficticio creado por MEE para ilustrar decisiones de especialización y aprendizaje. Los talleres, el piloto y las situaciones descritas pertenecen al ejercicio. No se ofrecen testimonios ni cifras de una empresa real. La referencia a Ries aporta un marco de preguntas, sin validar empíricamente los resultados del relato.
¿El primer producto debe resolver siempre un solo problema?
El caso propone delimitar una tarea para poder estudiarla con claridad. No establece una regla universal para todos los productos o sectores. Conviene identificar qué necesitas aprender y qué alcance permite comprobarlo. Una tarea puede requerir varias funciones, pero añadirlas necesita una razón y una revisión de recursos y compromisos.
¿Cuándo se puede pasar del piloto a más clientes?
Esta historia no fija un umbral válido para cualquier negocio. Revisa qué se comprobó, qué apoyo necesitó la prueba y qué capacidad exige atender más compromisos. Incluye límites de soporte y resultados pendientes. Que una muestra funcione con ayuda no demuestra que el proceso pueda sostenerse en condiciones distintas o con más participantes.
Para seguir aprendiendo
- Nicho primero: por qué empezar pequeño y concreto
- El salto a la capacidad vecina: cuándo y cómo ampliar
- Nichos: ser el mejor para pocos antes que mediocre para todos
Fuentes y alcance
Consulta y revisión: 03/11/2026. Los ejemplos hipotéticos y las pautas prácticas son propuestas de MEE. Se indica el alcance de las fuentes consultadas.
- Eric Ries · The Lean Startup · Methodology, presentación oficial. Presentación oficial del ciclo construir, medir y aprender. No libro íntegro ni validación empírica de la startup ficticia. Consulta: 03/11/2026.
