Expertos en startups analizan cómo hacer cosas que no escalan
- Aisha Washington
- hace 1 día
- 8 min de lectura
A los fundadores en etapas tempranas se les suele animar a pensar en la escalabilidad desde el principio. Se les pregunta cómo sus sistemas atenderán a millones de usuarios, cómo la adquisición de clientes se volverá repetible y cómo las operaciones crecerán sin que los costes aumenten al mismo ritmo. Son preguntas legítimas, pero los expertos en startups de esta conversación de Y Combinator sostienen que a menudo se plantean demasiado pronto.
Los ponentes retoman el influyente ensayo de Paul Graham, “Do Things That Don’t Scale”, y explican por qué su mensaje sigue siendo fundamental para crear una empresa desde cero. Mediante ejemplos de Airbnb, Fleek, Stripe, Algolia, Instacart y DoorDash, argumentan que el esfuerzo manual no es simplemente una concesión temporal aceptable. Si se utiliza deliberadamente, es una forma poderosa de poner a prueba la demanda, entender a los clientes y descubrir qué partes de un negocio realmente merece la pena escalar.
Por qué el mundo de las startups necesitaba un enfoque diferente
Según los ponentes, el entusiasmo de Silicon Valley por los sistemas escalables surgió en parte al observar empresas de internet extraordinariamente exitosas. Google demostró cómo el software y la distribución en línea podían llegar a audiencias enormes con un esfuerzo incremental relativamente pequeño. Naturalmente, fundadores e inversores empezaron a buscar modelos de crecimiento igual de repetibles.
Con el tiempo, esa ambición se convirtió en una limitación. Los emprendedores sentían presión por presentar una solución escalable antes de haber demostrado que alguien la necesitaba. Podían pasar meses diseñando sistemas automatizados para una demanda hipotética mientras permanecían alejados de los clientes reales.
El ensayo de Paul Graham cuestionó ese orden. Como explican los panelistas, la mayoría de las startups jóvenes no están amenazadas por una demanda excesiva ni por una infraestructura que se derrumba. Su riesgo inmediato es mucho más simple: quizá nunca atraigan suficientes usuarios o construyan algo que las personas no valoran.
Por tanto, la prioridad práctica es resolver el problema directamente, aunque el primer método requiera mucho trabajo. La escalabilidad importa con el tiempo, pero solo después de que la empresa haya encontrado algo que valga la pena escalar.
Llegar de cero a uno es lo primero
La conversación plantea el progreso de una startup como una serie de limitaciones inmediatas. Al principio, el reto no es atender eficientemente al cliente número un millón. Es conseguir al primer cliente, lograr el primer resultado exitoso y aprender por qué esa persona eligió el producto.
Esto cambia la forma en que los fundadores deberían evaluar el trabajo inicial. Una tarea que parece ineficiente en una empresa madura puede ser totalmente racional cuando responde rápidamente a una pregunta crítica. Incorporar personalmente a un cliente, preparar manualmente un servicio o improvisar un flujo de trabajo interno puede revelar más que semanas dedicadas a construir infraestructura de forma aislada.
Los ponentes utilizan Airbnb como ejemplo definitorio. Sus fundadores necesitaban mejores anuncios, así que ayudaron a los anfitriones a producir fotografías de mayor calidad. Viajar a las propiedades y mejorar cada anuncio de forma individual nunca podría haber sido el modelo operativo permanente. Sin embargo, resolvió el problema urgente de la empresa: hacer el mercado más atractivo y generar suficiente actividad para que comenzara el crecimiento.
La lección no es que todos los fundadores deban reproducir la táctica de Airbnb. Es que deben identificar el obstáculo que tienen justo delante y estar dispuestos a resolverlo sin esperar a contar con un sistema elegante.
Fleek aprendió el mercado antes de construirlo
Fleek ofrece una ilustración especialmente vívida del aprendizaje mediante operaciones manuales. La empresa comenzó sin una web terminada, sin inventario de ropa y sin una infraestructura sofisticada de mercado. En su lugar, sus fundadores fueron a mayoristas de Londres, desarrollaron relaciones y conectaron directamente la oferta con las tiendas.
El panel describe cómo el equipo incluso transportaba ropa entre mayoristas y minoristas. Desde una perspectiva convencional de eficiencia, que los fundadores llevaran la mercancía ellos mismos parece un fallo del proceso. Sin embargo, desde una perspectiva de aprendizaje, los situaba dentro de la transacción.
Al participar en el trabajo, Fleek podía observar qué querían los minoristas, cómo se comportaban los mayoristas, qué precios funcionaban y cómo respondía la demanda a los cambios. No eran respuestas abstractas de encuestas. Eran aprendizajes obtenidos mientras ayudaban a compradores y vendedores reales a completar compras reales.
Después de aproximadamente cuatro meses operando manualmente, los fundadores tenían suficiente conocimiento para trasladar la actividad a internet. El mercado se basó en comportamientos que el equipo ya había observado, en lugar de en supuestos sobre cómo debería funcionar el mercado.
La incorporación práctica crea mejores productos
Los ponentes señalan a Stripe y Algolia como otros ejemplos de fundadores que cerraron la brecha entre el desarrollo de producto y la realidad del cliente. Los fundadores de Stripe ayudaron a instalar su software de pagos para los primeros usuarios, en lugar de limitarse a enviar documentación y esperar. De manera similar, Algolia ayudó a Product Hunt a implementar la búsqueda.
La implementación directa logra más que activar una cuenta nueva. Expone pasos de configuración confusos, dependencias técnicas ocultas y diferencias entre lo que los clientes dicen necesitar y aquello con lo que realmente tienen dificultades en la práctica.
También puede cambiar la relación. Un cliente que ha trabajado junto a un fundador tiene más probabilidades de compartir comentarios sinceros que alguien que envía un ticket de soporte a una empresa desconocida. Esa confianza da a la startup acceso a una visión de producto más precisa.
Los panelistas describen esta atención personal —el “FaceTime” de los fundadores— como una ventaja que las empresas establecidas a menudo no pueden igualar. Un competidor grande puede tener más recursos, pero normalmente no puede hacer que sus fundadores se comprometan personalmente con el éxito de cada pequeño cliente. Para una startup con un producto incompleto y credibilidad limitada, una atención visible puede convertirse en parte de la propuesta de valor.
Optimiza el trabajo inicial para aprender
El argumento central de la conversación es que los fundadores deberían optimizar la fase inicial para aprender, en vez de hacerlo para lograr elegancia operativa. La entrega manual ayuda a establecer si el resultado prometido realmente tiene valor antes de que el equipo codifique ese proceso en software.
Este principio puede traducirse en una secuencia sencilla:
Identifica la incertidumbre más importante del negocio.
Diseña la forma creíble más rápida de probarla con clientes reales.
Realiza el trabajo manualmente cuando automatizarlo retrasaría la respuesta.
Registra lo que crea valor de forma repetida o genera fricción.
Construye sistemas solo después de que el patrón quede claro.
Esto no significa tratar cada proceso improvisado como prueba de un negocio viable. El trabajo manual resulta útil cuando genera evidencia. Los fundadores aún deben determinar si la demanda se repite, si los clientes pagarán y si el servicio subyacente puede sostener finalmente un modelo de negocio atractivo.
Lo que deberían evitar es confundir el refinamiento técnico con la validación. Una plataforma magníficamente diseñada no puede compensar un producto que nadie desea.
Instacart y DoorDash pusieron a prueba la demanda con herramientas improvisadas
La historia de Instacart muestra cómo los fundadores pueden probar un mercado antes de conseguir todas las alianzas que requeriría una versión madura. Según se relata en el video, la empresa se lanzó sin relaciones formales con tiendas de comestibles. El equipo compraba productos en Trader Joe’s, los fotografiaba y los publicaba en línea para comprobar si los clientes pedirían comestibles a domicilio.
Ese enfoque evitó un ciclo potencialmente largo de negociaciones de alianzas. En vez de pedir a los minoristas que respaldaran un concepto sin demostrar, los fundadores primero reunieron evidencia de que los consumidores querían el servicio.
DoorDash siguió una ruta igualmente pragmática. Los ponentes describen su producto inicial como algo montado en un solo día con herramientas comunes, entre ellas Google Drive y Find My Friends. El objetivo no era crear de inmediato una plataforma logística duradera. Era averiguar si los consumidores locales pedirían comida de restaurantes a domicilio y si los fundadores podían cumplir esos pedidos.
Estos experimentos aprovecharon una ventaja real de las startups: los equipos pequeños pueden coordinar temporalmente el trabajo de maneras que resultarían poco prácticas para las grandes organizaciones. Tienen menos procesos que proteger, menos infraestructura que integrar y más libertad para cambiar de dirección después de cada resultado.
Los sistemas imperfectos aceleran la adaptación
Hacer las cosas manualmente permite a un equipo revisar la experiencia sin reconstruir un producto entero. Si a los clientes no les gusta un paso, los fundadores pueden cambiarlo en el siguiente pedido. Si un supuesto resulta falso, pueden abandonarlo antes de que quede incorporado en meses de trabajo de ingeniería.
Los ponentes también sostienen que los fundadores no deberían temer en exceso los errores operativos iniciales. Los problemas creados por la creciente demanda suelen generar fuertes incentivos para encontrar soluciones rápidamente. Cuando una startup finalmente tiene más usuarios de los que su proceso improvisado puede soportar, la necesidad de automatización se vuelve concreta, urgente y más fácil de definir.
Por eso las startups rara vez fracasan porque atrajeron demasiados clientes y no pudieron escalar. Los problemas de capacidad son dolorosos, pero vienen acompañados de evidencia de demanda. La falta de usuarios es mucho más peligrosa porque no ofrece ni ingresos ni una razón clara para seguir construyendo.
La implicación para la ingeniería es importante: posponer la infraestructura puede ser una forma de avanzar más rápido, no una negligencia, siempre que se comprendan los atajos y no creen riesgos inaceptables para los clientes.
Saber cuándo construir para escalar
El trabajo no escalable es un método de descubrimiento, no una filosofía permanente. Una vez que una startup comprende el trabajo recurrente, observa una demanda sostenida y se encuentra con cuellos de botella manuales, debe empezar a convertir lo aprendido en sistemas repetibles.
El panel señala que asesores e inversores experimentados pueden ayudar a los fundadores a reconocer esta transición. Escalar demasiado pronto desperdicia recursos en supuestos no verificados. Escalar demasiado tarde puede dañar la calidad del servicio, agotar al equipo e impedir que la empresa capture la demanda.
Una señal útil es la repetición. Si los fundadores siguen resolviendo el mismo problema aproximadamente de la misma manera, el software puede ser capaz de estandarizar el proceso. Otra es el coste de oportunidad: cuando la entrega manual consume tiempo que podría generar aprendizajes o crecimiento más valiosos, la automatización se vuelve cada vez más atractiva.
El objetivo no es eliminar la participación humana por sí misma. Es automatizar las partes que ya se comprenden, preservando al mismo tiempo el contacto cercano allí donde los clientes todavía están enseñando a la empresa algo importante.
La consultoría puede ser un puente, pero no el destino
Los ponentes también abordan la frontera entre una startup de software y una consultora. Una empresa joven puede generar ingresos ofreciendo servicios prácticos a negocios, y su primer producto puede limitarse a hacer ese servicio más rápido o fiable.
Esto puede ser un punto de partida productivo. El trabajo de consultoría expone a los fundadores a entornos operativos reales y les aporta un conocimiento detallado de los problemas de los clientes. También puede financiar el desarrollo inicial.
Sin embargo, el panel advierte que los ingresos por servicios por sí solos no crean una empresa de software de alto crecimiento. El trabajo personalizado crece principalmente añadiendo personas, mientras que un producto escalable puede atender a muchos más clientes sin un crecimiento proporcional de la plantilla. Los objetivos de crecimiento ambiciosos ayudan a forzar la distinción: si se espera que el negocio crezca un orden de magnitud, los fundadores deben terminar convirtiendo la experiencia repetida en un producto, en lugar de vender indefinidamente trabajo a medida.
La ventaja duradera del esfuerzo del fundador
El mensaje final del video es que la disposición a realizar tareas incómodas, manuales o aparentemente menores es una de las ventajas más sólidas de una startup frente a competidores establecidos. Ese trabajo acerca a los fundadores a los clientes, acelera los experimentos y crea oportunidades para ofrecer un servicio excepcionalmente atento.
El principio más profundo no es una celebración de la ineficiencia. Es una secuenciación disciplinada. Primero, aprende lo que las personas necesitan. Después, demuestra que actuarán en función de esa necesidad. Entrega el resultado mediante cualquier método responsable que esté disponible, estudia el patrón recurrente y solo entonces invierte en hacerlo repetible.
La escalabilidad se vuelve valiosa cuando la demanda se la ha ganado. Antes de ese momento, el sistema más efectivo del fundador puede ser simplemente la curiosidad, la urgencia y la disposición a hacer el trabajo personalmente.
