Las startups son esencialmente máquinas que construyen MVP (productos mínimos viables) que ayudan a responder preguntas y gradualmente reducen el riesgo de la propuesta de valor de la empresa.
La clave es que cada MVP que crea una empresa debe centrarse con láser en responder una pregunta muy particular. Si hace algo más que eso, es tiempo y esfuerzo desperdiciados. En mi experiencia, muchas empresas emergentes se preocupan por escalar demasiado pronto, desperdiciando recursos en algo que quizás nunca se necesite.
Esta tendencia es particularmente evidente en las nuevas empresas fundadas por personas que provienen de disciplinas de ingeniería en grandes empresas ya escaladas. Pero las cosas que debe hacer para enviar código en Facebook, Netflix, Amazon o Google no se aplican de la misma manera a las nuevas empresas en etapa inicial.
Las nuevas empresas en etapa inicial pueden tener unos cientos o miles de clientes, y cada lista de clientes tiene su propio conjunto único de desafíos.
No hay que malinterpretar; siempre es mejor asegurarse de que el código sea relativamente seguro y que esté escrito de tal manera que no degrade la experiencia del cliente. Pero los fundadores técnicos a menudo se equivocan y dedican mucho tiempo a fortalecer el código (es decir, hacerlo seguro), además de escribirlo e implementarlo de tal manera que sea escalable.
Pero eso no funciona del todo cuando estás en modo de prueba de concepto.
Los fundadores sin experiencia a menudo se ponen a la defensiva con este tipo de cosas, preocupándose demasiado por si el producto o la función que acaban de crear ofrecerá una experiencia de usuario perfecta o preocupándose por si puede manejar un millón de usuarios simultáneos. Sí, esas cosas son importantes, pero es posible que no estén bien en este momento exacto.
La mentalidad en las nuevas empresas en etapa inicial debe ser que está creando MVP para responder preguntas. Hay que tener en cuenta que MVP sigue siendo un término terrible; no es ni un producto ni viable. Tampoco es tan “mínimo” en muchos casos. Un MVP es la menor cantidad de trabajo que puede hacer para confirmar o rechazar una hipótesis para su inicio.
Si la hipótesis es, «¿Pueden un millón de clientes usar esta aplicación al mismo tiempo?» por supuesto, ese es el momento adecuado para optimizarlo a una pulgada de su vida útil. Pero, cuando está construyendo una empresa en los primeros días, esa rara vez es la pregunta y, a menos que se encuentre en categorías particulares de aplicaciones que deben ser resistentes a cantidades notables de tráfico, es poco probable que a los inversionistas les importe.
En una de las empresas emergentes en la que colaboré, la empresa tenía un producto en el que se ponía a decenas de miles de personas en una sala de espera y, cuando terminaba un reloj de cuenta regresiva, todos podían entrar al producto. Eso resultó ser un desafío interesante: ¿Qué sucede cuando 10,000 personas acceden exactamente a la misma parte de una aplicación web con un segundo de diferencia?
Como se puede imaginar, incluso las pequeñas ineficiencias en la plataforma causaron grandes cuellos de botella y una posible degradación del servicio. A corto plazo, «se resolvió» el problema activando un montón de servidores adicionales y luego dejando entrar a la gente en unos minutos; tener 500 personas presionando el código ligeramente ineficiente a la vez fue un problema mucho menor que tener 10,000 personas ingresando todas a la vez.
¿Elegante? No. ¿Funcionó? Sí, y tenía sentido porque, en ese momento, a la empresa no le preocupaba explícitamente si el servicio podría atender a 100.000 clientes al mismo tiempo. Alerta: no podía, y en el momento necesario, esa parte del código había sido refactorizada de una manera que aseguraba que pudiera hacerlo.
En las primeras etapas, las preguntas tienden a ser las siguientes: «¿Es posible lo que estamos tratando de hacer?» o «¿Pagará la gente por esto?» o «¿Podemos convencer a un socio corporativo para que integre esto?» o «¿Podemos adquirir clientes a un costo razonable?» o «¿Podemos fabricar esto a un precio que tenga sentido?» o «¿Cómo funciona la economía unitaria de este producto a medida que escalamos?»
Para una empresa de presemillas, no se necesita un diseño y escalabilidad perfectos; se necesita crear suficiente producto y tracción para obtener comentarios de los usuarios. A partir de ahí, puede iterar y crear valor para los clientes. Una vez que se empiece a generar suficiente valor que los clientes estén dispuestos a pagar, puede comenzar a considerar invertir más en escalabilidad.
La ingeniería excesiva de un producto demasiado pronto no es importante ni inteligente. Es un contraindicador: les dice a los inversores que no sabes qué es importante en la etapa actual de tu startup.
Cuando se enfoque la atención, se ejecuta la prueba de fuego: ¿Su actividad actual está contribuyendo a obtener garantías que lo ayuden con su próxima ronda de recaudación de fondos? Si no es así, probablemente está trabajando en algo que parece súper importante, pero que no es apropiado para el escenario.
Esto es un problema: siempre podría dedicar más tiempo a crear algo más elegante, más rápido, más bonito o más escalable, pero el mantra en el inicio debe ser «lo suficientemente bueno es lo suficientemente bueno». Es sorprendente lo rápido que se puede ir una vez que la empresa lo internalice.
