¿Por qué las empresas nuevas prueban una versión pequeña antes de terminar su producto?

El riesgo más grande de una empresa nueva es construir lo que nadie quiere

Tom Eisenmann, profesor de gestión de emprendimientos en la Escuela de Negocios de Harvard (Estados Unidos), lo resume así: muchas empresas nuevas fracasan porque construyen un producto que la gente no necesita, tardan demasiado en hacerlo y gastan mucho dinero, primero en fabricarlo y luego en intentar venderlo. El tiempo es dinero; cuando el dinero se acaba, la empresa se hunde [1].

Frente a eso existe un enfoque llamado «lean startup» (en español se suele decir «empresa emergente austera» o, simplemente, se deja el nombre en inglés). La palabra «lean» viene del Sistema de Producción de Toyota y aquí se refiere a trabajar sin desperdiciar recursos: la idea central es evitar el derroche de tiempo y de dinero. En lugar de pasar meses puliendo en secreto un producto con todas las funciones, la empresa sale lo antes posible con lo que su creador, Eric Ries, llama un producto mínimo viable (MVP, por sus siglas en inglés): un producto con las funciones justas para que los primeros usuarios puedan dar opiniones útiles [1].

El propio Eisenmann reconoce que la idea es polémica, porque puede parecer algo hecho deprisa y con cuatro remiendos. Su defensa es que, con una serie de versiones mínimas, una empresa puede comprobar de forma ordenada las suposiciones sobre qué es su negocio y qué necesita hacer [1].

Aardvark empezó con personas respondiendo detrás de una cortina

Uno de los casos que Eisenmann enseña en sus clases es Aardvark, un servicio en el que alguien hace una pregunta y recibe la respuesta a través de la red de amistades de sus amistades. Sus creadores no empezaron programando toda la tecnología. Lanzaron el servicio con personas que, sin que los usuarios lo vieran, repartían las preguntas «detrás de la cortina» en lugar de hacerlo un programa [1].

La expresión viene de la novela El maravilloso mago de Oz, donde el gran mago resulta ser un hombre que maneja una máquina escondido tras una cortina. El artículo de Harvard dice que Aardvark usó un método «inspirado en el mago de Oz» [1].

Esto responde a la pregunta del título. Construir la tecnología de verdad cuesta tiempo y dinero. Si, mientras se hace el trabajo a mano, se observa qué preguntan los usuarios y cómo, el equipo puede dedicar después su dinero a una tecnología que encaje con lo que la gente hace realmente [1]. Es una forma de «probar el disfraz antes de coser el traje».

Dropbox salió con una versión básica y la fue mejorando con las opiniones recibidas

El otro caso es Dropbox, el servicio para guardar archivos en internet. Su equipo anunció primero una versión muy básica en Hacker News, un sitio web donde se comentan noticias de tecnología. Recogió enseguida muchísimas opiniones de quienes lo leían y las fue incorporando en lanzamientos sucesivos, cada uno con solo un par de funciones nuevas [1].

El artículo cuenta que, en ese proceso, Dropbox pasó de 100 000 a 4 millones de usuarios en 15 meses [1]. Si divides 4 000 000 entre 100 000, el resultado es 40: el número final era unas 40 veces el inicial. Conviene leer ese dato con cuidado. La división solo dice cuánto creció en total; no cuenta cómo creció mes a mes. Y el texto no afirma que todo el aumento se debiera a la versión básica inicial. Lo que sí muestra el caso es que salir pronto con algo sencillo permite escuchar a los usuarios desde el primer momento.

Para elegir entre dos versiones se usa una prueba A/B

Cuando ya hay usuarios, aparece otra duda: ¿es mejor un botón rojo o uno azul? Una prueba A/B responde con datos en lugar de opiniones. Según la documentación técnica del gobierno del Reino Unido, consiste en crear dos o más versiones completas de una página web, repartir las visitas entre ellas y mostrar a cada persona una versión al azar; después, un análisis estadístico indica cuál funciona mejor para un objetivo de conversión definido (por ejemplo, que la gente pulse un botón) [2].

Esa misma documentación pide escribir antes de empezar una hipótesis con la forma «Si…, entonces…, porque…»: qué vas a cambiar, qué resultado esperas y por qué lo esperas [2]. Un ejemplo inventado para esta página: «Si pongo el botón rojo, entonces más personas lo pulsarán, porque destaca más». Escribir el «porque» sirve para algo muy práctico: si el resultado sale distinto, sabes qué suposición revisar.

El reparto al azar importa. El manual de estadística del NIST, el instituto de metrología de Estados Unidos, explica que «aleatorizar» significa decidir al azar el orden de las pruebas, y propone un método casero: meter en una caja papelitos con cada condición y sacar uno sin mirar antes de cada ensayo [3]. Así se reducen algunos sesgos, por ejemplo el de probar siempre una versión al final del día, cuando las circunstancias son otras, aunque el azar todavía puede influir en los resultados.

Cuando una hipótesis falla, se puede cambiar de rumbo

¿Qué pasa si la prueba demuestra que la idea no funciona? En este enfoque no se ve solo como un fracaso. Eisenmann llama «pivotar» a hacer un cambio importante: dirigirse a otro tipo de clientes, añadir o quitar funciones del producto o cambiar la forma de cobrar. Lo ideal, dice, es pivotar después de una prueba decisiva que haya refutado una hipótesis, y luego plantear nuevas suposiciones para volver a probarlas [1].

El propio profesor admite que pivotar es muy difícil: quien fundó la empresa convenció a empleados, inversores y clientes de una idea, y cambiarla puede parecer una traición [1]. También avisa de que este método es más fácil de aplicar a servicios web que a campos como la biotecnología o las energías limpias, donde hace falta mucho tiempo y dinero para tener un primer prototipo que funcione [1]. Es decir, probar en pequeño no vale igual para todo.

En casa: una prueba A/B con dos aviones de papel

Puedes copiar la estructura con material que ya tienes. Esta propuesta es una adaptación de las ideas anteriores, no un procedimiento de las fuentes.

1. Hipótesis. Haz dos aviones iguales con papel del mismo tamaño y la misma manera de doblar el papel, pero con alas grandes en el A y pequeñas en el B. Escribe: «Si hago las alas más grandes, entonces el avión llegará más lejos, porque el aire lo sostendrá más».
2. Condiciones iguales. Que lance siempre la misma persona, desde el mismo sitio.
3. Orden al azar. Lanza cada avión 5 veces (10 lanzamientos). Escribe «A» cinco veces y «B» cinco veces en papelitos, mézclalos en un bote y saca uno antes de cada lanzamiento, como en el método del NIST [3].
4. Medir. Anota la distancia en baldosas o en pasos.
5. Comparar. Calcula el promedio de cada avión y mira también cuánto varían los 5 lanzamientos. Si los resultados de A y B se mezclan mucho, con solo 10 lanzamientos no puedes concluir que uno llegue más lejos.
6. Pivotar. Si salió distinto de lo que esperabas, revisa el «porque» de tu hipótesis y cambia una sola cosa, por ejemplo el ángulo de un pliegue.

Dos precauciones: no lances aviones hacia personas, animales ni objetos frágiles, y, si pides a alguien que juegue contigo, pregúntale antes y respeta su respuesta si dice que no.

Si quieres ir más lejos, las fuentes de abajo son un buen punto de partida: el artículo de Harvard cuenta los casos con más detalle, y la guía del gobierno británico y el manual del NIST explican cómo se plantea una prueba para que sus resultados se puedan creer.