Haz cosas que no escalan (2013)

 (paulgraham.com)
3 puntos por GN⁺ 2025-08-17 | 1 comentarios | Compartir por WhatsApp
  • Y Combinator aconseja que, en las primeras etapas de una startup, hay que hacer activamente 'cosas que no escalan'
  • Startups exitosas como Stripe y Airbnb eligieron un enfoque directo y agresivo para captar a sus primeros usuarios
  • La mayoría de las startups son muy frágiles al inicio, y el esfuerzo manual de los fundadores es clave para crecer
  • Ofrecer a los primeros usuarios una experiencia sobresaliente y satisfactoria es importante para el crecimiento a largo plazo
  • En la etapa inicial, suelen funcionar mejor el trabajo manual en vez de la automatización, atacar un nicho de mercado y la consultoría directa

Introducción: la realidad del crecimiento en una startup

  • Muchos futuros fundadores creen que una startup crece por sí sola, pero en realidad los fundadores deben involucrarse directamente para encender la chispa del crecimiento
  • Como la antigua manivela para arrancar un auto, al comienzo es indispensable un proceso intensivo en trabajo manual

Reclutar usuarios directamente (Recruit)

  • La mayoría de las startups no deben esperar pasivamente a que los usuarios lleguen solos, sino salir a buscarlos directamente
  • En el caso de Stripe, al principio usaron una estrategia agresiva de adquisición llamada 'Collison installation', en la que tomaban la laptop de la otra persona e instalaban ellos mismos la beta
  • La razón por la que los fundadores evitan hacer esto suele ser el miedo al rechazo, la vergüenza y subestimar lo poco que parecen significar unos cuantos usuarios
  • En realidad, por el efecto del crecimiento compuesto, incluso mantener un crecimiento semanal del 10% puede llevar a millones de usuarios en dos años
  • Airbnb también fue tan proactivo que iba directamente a buscar anfitriones en Nueva York y ayudaba a registrarlos

La fragilidad de las startups tempranas (Fragile)

  • Casi todas las startups son muy inestables al principio, y el éxito o el fracaso puede depender de esfuerzos directos en periodos muy cortos
  • Más peligrosa que la indiferencia de críticos o inversionistas externos es la tendencia de los propios fundadores a subestimar el valor de su empresa
  • Al inicio, en vez de preguntarse '¿esta empresa cambiará el mundo?', hay que preguntarse 'si hacemos el esfuerzo correcto, ¿hasta dónde podría crecer?'
  • Como ejemplo, Microsoft y Airbnb también parecían muy poca cosa en sus comienzos, aunque iban por el mejor camino posible
  • Los usuarios adecuados suelen encontrarse primero entre personas parecidas a uno mismo o identificando, entre los primeros usuarios, al grupo más entusiasta para enfocarse en él

Maximizar la alegría del usuario (Delight)

  • No solo hace falta reclutar usuarios, sino también hacer esfuerzos extraordinarios para dar una satisfacción excepcional a los usuarios existentes
  • Wufoo construyó confianza al principio con un servicio tan extremo que enviaba cartas de agradecimiento escritas a mano a cada nuevo registro
  • No hay que quedar atrapado en las reglas convencionales del servicio al cliente de las grandes empresas; conviene resaltar la experiencia personalizada que solo una startup naciente puede ofrecer
  • Si hacer felices a los primeros usuarios llega a volverse tan abundante que resulta difícil de manejar, eso puede ser, de hecho, una señal positiva de crecimiento
  • Una de las razones por las que los fundadores novatos en atención al cliente no aprovechan del todo la ventaja competitiva de una empresa pequeña es la falta de experiencia en servicio al cliente

Obsesión por la experiencia de usuario (Experience)

  • Como decía Steve Jobs con la expresión 'Insanely great', al principio hace falta obsesionarse con la experiencia de usuario
  • Más importante que un producto inicial totalmente terminado es mejorarlo mediante la interacción con los usuarios, aunque todavía sea imperfecto
  • La retroalimentación que se obtiene al conectar directamente con los usuarios tiene el mayor impacto en el crecimiento

Empezar con un mercado pequeño (Fire)

  • Como Facebook y Airbnb, conviene comenzar de forma deliberada en un mercado muy pequeño (por ejemplo, estudiantes de Harvard) y usar esa estrategia para alcanzar masa crítica dentro de ese grupo
  • Al inicio, resulta más efectivo encontrar al grupo de early adopters que reacciona más rápido
  • Programas de aceleración como YC también pueden ser útiles para entrar a un mercado donde otras startups sean los clientes

Estrategia especial para startups de hardware (Meraki)

  • En las startups de hardware, como el costo de producir en masa al principio es alto, los fundadores ensamblan el producto ellos mismos, como hicieron Meraki y Pebble
  • Al fabricarlo directamente, se genera un aprendizaje empírico sobre cómo optimizar el diseño y conseguir componentes

Enfoque extremo al usuario como consultoría (Consult)

  • En productos B2B, se puede construir algo a la medida para un solo cliente, como si fuera consultoría, y luego expandirse a mercados adyacentes
  • La pista para crecer aparece en el proceso de ajustarse por completo al problema que el cliente realmente necesita resolver
  • Al principio, también puede servir usar el software en lugar del cliente o incorporar de inmediato las funciones necesarias

Estrategia totalmente manual (Manual)

  • Cuando hay pocos usuarios, es posible procesar el trabajo manualmente y luego pasar de forma gradual a la automatización
  • Al principio, Stripe manejaba la 'apertura instantánea de cuentas' manualmente para transmitir esa experiencia al usuario
  • En vez de obsesionarse con automatizar desde el primer día, lo prioritario es entender los problemas reales del producto y del cliente a través del trabajo manual

La ineficiencia del 'gran lanzamiento' (Big)

  • Las estrategias de lanzar algo a lo grande de una sola vez o dejar el crecimiento en manos de alianzas con grandes empresas suelen fracasar
  • Al principio hay que concentrarse en conseguir unos pocos usuarios, y son más importantes el esfuerzo intenso y los métodos directos
  • La atención de los usuarios crece poco a poco, mediante gestión directa y ofreciendo satisfacción

Un enfoque bidimensional de la idea de startup (Vector)

  • Las startups exitosas deben pensarse como un vector de producto (qué construir) + estrategia no escalable (qué hacer directamente al principio)
  • Ese tipo de acción directa al inicio deja una huella positiva en el ADN del producto
  • Con el tiempo, ese esfuerzo directo inicial se transforma en producto y cultura organizacional, y se convierte en el motor de un crecimiento sostenido

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-17
Opiniones de Hacker News

  • Hace poco escuché algo en un pódcast con lo que conecté muchísimo: el mayor problema de una startup es la inercia. Al mundo no le gustamos tanto ni siente que nos necesite... nosotros tenemos que darle la vuelta a eso. Hay que crear momentum completamente desde cero, y la labor realmente importante del fundador es hacer cosas que reviertan esa inercia. Eso también pasa literalmente en física. El mundo está detenido, y nosotros tenemos que generar ese impulso inicial como si estuviéramos arrancando un motor. Viéndolo así, no tiene nada de raro hacer al principio cosas que no escalan. No se trata de optimizar una máquina que ya está funcionando, sino de ir moviendo pieza por pieza hasta que el motor empiece a girar bien. El punto de Paul Graham es que el crecimiento escalable o la automatización vienen después. Solo al acercarte manualmente a cada usuario puedes aprender de verdad qué funciona. Es un proceso de acumular evidencia de que el usuario te considera necesario, mientras demuestras qué vale la pena escalar

    • Creo que el verdadero valor del trabajo manual está en lo que aprendes directamente. Uno de mis clientes ofrecía una lista curada de noticias financieras y bursátiles importantes cada semana, seleccionadas a mano. Era un nicho dentro de otro nicho pequeño, pero a los usuarios les encantaba. En algún momento intentaron automatizarlo todo, y como resultado aumentó la cantidad de contenido sin criterio, empezó a colarse información tipo spam, se perdió el valor y al final el producto también terminó yéndose por ese camino. Metieron más noticias, pero al dejar de seleccionarlas y editarlas manualmente, la relación señal-ruido empeoró. En la práctica, el trabajo manual era mucho más valioso aunque su alcance fuera limitado. Muchas empresas no entienden eso y se obsesionan demasiado pronto con automatizar. Otro ejemplo: tuve un cliente que revisaba manualmente los precios de la competencia. Quería automatizarlo, así que hice un scraper sencillo basado en Excel. Al principio quedó satisfecho, pero después se dio cuenta de que, al dejar de navegar directamente los sitios de la competencia, estaba perdiendo oportunidades para aprender sobre nuevos productos, tendencias en catálogos y demás. Al final volvió a explorar manualmente, y dejó el scraper solo para análisis simple de precios. Pero la mayoría de mis otros clientes siguen concentrándose solo en la automatización y no en la esencia del producto y del problema, así que se pierden oportunidades de aprendizaje importantes

    • Por eso “haz algo que la gente quiera” es una frase tan célebre en el mundo startup

    • Me encantó la expresión “revertir la inercia”, pero este enfoque no aplica a todas las startups. Según el framework Arc de Sequoia, hay tres formas: Hair on Fire (dolor urgente, donde el momentum es clave), Hard Fact (hay dolor, pero el usuario debe cambiar hábitos) y Future Vision (la gente todavía ni cree que eso sea posible, así que primero hay que construir confianza). Obtener resultados haciendo tú mismo cosas que no escalan es esencial en el terreno Hair on Fire, pero en los otros casos se trata más de reconfigurar la realidad misma o de construir credibilidad primero

  • Mi teoría es que se puede dividir en tres etapas: Not Scaling (antes de escalar), Scaling (escalar) y Antiscaling (la etapa antipática). Not Scaling es cuando construyes tu propio moat en el mercado. Scaling es cuando el producto ya es lo bastante popular como para que los clientes traigan a nuevos clientes, y solo tienes que lidiar con el aumento de demanda partiendo servidores o bases de datos. Antiscaling es cuando te conviertes en el tipo de empresa que representa los problemas de la web moderna. Cuando agencias de inteligencia te contactan por el uso que hacen terroristas de tu servicio, y ayuntamientos o gobiernos crean licencias o regulaciones específicamente para apuntarte. Cuando el fundador se vuelve famoso, se vuelve meme y hasta lo pueden rastrear. No hace falta dominar el mundo, solo ganar dinero. La gente que dice que va a cambiar el mundo rara vez termina produciendo algo realmente bueno, así que lo importante es hacer algo útil

    • La frase “solo hay que ganar dinero” me recuerda a la ley de Goodhart: cuando una métrica (por ejemplo, ingresos) se convierte en el objetivo, deja de ser una buena métrica

    • Siento que esta visión está demasiado sesgada. Aquí no se habla de la indiferencia extrema que ocurre cuando construyes algo que nadie quiere. Y en realidad el caso más común es otro: un éxito apenas moderado y bastante promedio. Nadie lo odia, pero tampoco hay gente que lo ame con locura. Es algo ligeramente positivo, pero sin hype ni ventaja competitiva exclusiva, y a casi nadie le importa demasiado. Ese caso es probablemente el más frecuente

  • Dejo los enlaces de abajo porque me gustaría reunir más casos relacionados

  • Quiero compartir esto porque se lo recomendaría a todos los fundadores en etapa inicial y también a quienes se sumaron temprano como empleados. Nosotros ya superamos las 15 personas y aun así llamamos directamente a cada nuevo registro. Lo hacemos por tres razones: 1) saber cómo nos conocieron 2) ver si necesitan ayuda para empezar a usar el producto 3) transmitir, aunque sea de forma implícita, que nuestro equipo realmente les presta atención. En nuestro caso parece funcionar mejor porque somos una plataforma B2B, y aunque el público son desarrolladores, cuando de verdad llamas, una vez que superan el “no, no les estoy queriendo vender nada”, suelen salir conversaciones muy sinceras y muy buenas

  • Hay muchas críticas a Paul Graham, pero este texto en sí se puede resumir como una advertencia contra la optimización prematura. Es decir, no actúes como si ya fueras una gran empresa. Si el fundador mete las manos directamente en el trabajo, aunque sea ineficiente, puede acumular experiencia real y feedback. Y al no implementar desde el principio soluciones escalables, también puede recibir feedback más rápido. Además, sirve para crear una diferenciación propia. Creo que vale la pena grabarse literalmente la idea de “haz cosas que no escalan”

    • Muchas veces la gente construye sistemas excesivamente escalables desde una etapa en la que todavía no hacen ninguna falta, porque les preocupa que el servicio colapse por una popularidad o demanda excesivas. Pero yo siento que el escalado vertical (simplemente agregar más recursos) está muy subestimado. Incluso solo metiéndole más recursos a un backend monolítico ya puedes ganar tiempo para entender bien el servicio. Y sobre todo, te obliga a replantearte cuál es el “valor central” que de verdad le gusta al usuario de tu producto. Además, si los usuarios realmente aman tu producto, al principio te perdonan un rendimiento algo flojo. En los inicios de Twitter aparecía seguido la “fail whale”, pero creció de forma explosiva porque la función que la gente quería sí funcionaba. En la etapa inicial todo es feedback rápido, iteración y satisfacción del cliente. Antes que escalar, van los experimentos, la comunicación con usuarios y la observación. Tiene sentido preocuparse por escalar cuando realmente te llegue ese momento de intuición, y ese momento no se puede predecir. La tecnología es solo una herramienta; aunque tengas un violín de lujo, primero tienes que hacer “buena música”

    • También hay que recordar que no todos los negocios exitosos apuntan a cientos de millones o miles de millones de usuarios. Yo trabajo creando herramientas internas, y el tamaño de nuestro entorno ya está definido, no somos especialmente sensibles al rendimiento y tampoco tenemos tráfico irregular. Aun así, en nuestro equipo hubo alguien obsesionado con reescribir todo el código en un lenguaje que solo él conocía para ahorrar unos cuantos milisegundos. A nadie le importaba, y lo único que dejó fue un riesgo de mantenimiento. Cuando se fue de la empresa, por decisión de la gerencia tiraron todo eso a la basura; si hubiera sido un diseño más simple y más lento, a otra persona le habría resultado mucho más fácil recibirlo y mantenerlo

    • “Optimización prematura” y “Do Things That Don’t Scale” no son exactamente lo mismo. La primera asume sutilmente que la versión escalable es la “óptima”, mientras que la segunda sugiere que una forma no escalable podría ser incluso la mejor. Por ejemplo, que el CEO personalmente se encargue de los contactos puede ser mucho mejor que una bandeja compartida que procese todo. La forma que escala (un formulario de contacto) no es una optimización desde el inicio, sino en la práctica una degradación de la calidad del proceso. Escalar no es malo en sí, pero trae consigo complejidad y distancia con el cliente. Hay que reconocer que, según el caso, el proceso puede empeorar. Para mí, el mensaje se parece más a “evita degradar prematuramente el proceso”

    • En resumen, se puede reducir a “no intentes resolver por adelantado problemas que todavía no existen”

    • El consejo de “no actúes como una gran empresa” sinceramente aplica a organizaciones de cualquier tamaño. Como consultor, paso mucho tiempo frenando a startups y pymes que quieren adoptar reglas y políticas de organizaciones enormes solo porque son una empresa formal. Esas políticas recién tienen sentido en estructuras de cientos de personas; en organizaciones pequeñas más bien terminan estorbando. Por ejemplo, k8s, nosql o políticas de seguridad más rígidas de lo necesario. La guía cultural interna de Netflix también muestra bien esto. Si tu organización es pequeña, y asumiendo que contrataste bien, lo que corresponde es delegar de verdad y permitir que cada integrante use su criterio. No hace falta encerrar todo en reglas hasta que los problemas o riesgos realmente crezcan

  • Stripe es una de las empresas más exitosas del portafolio de YC, y el problema que resolvió Stripe era realmente urgente y apremiante. En una situación en la que cualquiera habría salido a esperar a que llegaran los usuarios, Stripe se hizo famoso por una adquisición de usuarios muy agresiva. Eso fue hace 12 años, y yo no imaginaba que fueran a crecer tanto. Ojalá hubiera podido invertir en ese momento

  • Claro que hay survivor bias. Pero coincido por completo con la idea de que importa mucho ese periodo en el que haces el trabajo tú mismo y no automatizas. Es la única forma de grabarte en la cabeza todo el proceso o sistema con un nivel de precisión que no consigues solo con slides o documentos. En términos actuales, también se podría llamar desarrollar “taste”. Es el periodo en que adquieres sensibilidad para reconocer qué es bueno y por qué, y empiezas a formar una postura clara en puntos de decisión que otros ni siquiera se plantean. Hoy, con la IA, hay demasiados lugares queriendo saltar demasiado rápido hacia la automatización, pero en www.socratify.com nosotros seguimos creando el contenido manualmente. Todo el mundo dice que hay que hacerlo con IA, pero nuestro objetivo principal es curar bien el contexto y la calidad. Más adelante tal vez podamos automatizar parte del proceso de validación, pero por experiencia indirecta hemos visto muchas veces que reemplazar por completo el cerebro y la intuición humana simplemente no es realista

  • YC cambió el panorama al hacer que el seed funding fuera mucho más accesible. Estoy convencido de que Paul Graham, Jessica Livingston y el equipo de YC vieron correctamente los problemas del sistema anterior y los arreglaron. Antes de YC, conseguir seed funding era casi imposible. Era desigual, y se sentía como presentar ante ocho socios enojados en una vieja oficina bancaria. Si algo hay que reconocerles, es justamente eso: ellos corrigieron ese mercado

    • Creo que esta parte es debatible. Aunque el acceso al financiamiento se abrió a más gente, en realidad tanto antes como después de YC el seed funding sigue siendo difícil. La diferencia es que, con la aparición de un actor tan grande como YC, la posición de los fundadores que hacen bootstrapping se debilitó más. En algún momento empezó a pasar que los fundadores ya no seguían lo que realmente querían hacer, sino los temas que YC elegía. Se redujo la oportunidad de que un fundador hiciera aquello en lo que de verdad quería volverse experto

  • Ojalá grandes empresas como OpenAI leyeran “Do Things That Don’t Scale” en serio y lo tomaran como referencia real. Con ese nivel de capital, podrían haber pagado legítimamente las licencias de datos necesarias. Pero eligieron solo la vía que escala (scraping, stealing) y pareciera que apostaron a usar un montón de cosas sin permiso esperando que nadie se diera cuenta, o que los reclamos llegaran demasiado tarde. Básicamente confiaron en que la situación actual, en la que los creadores de contenido ni siquiera saben que su trabajo se usó para entrenar IA y no reciben ni un centavo por ello, simplemente pasara sin consecuencias

    • Yo veo esto menos como un problema de escalado y más como algo ligado al impulso inevitable del capitalismo de “no querer gastar dinero”

  • Este fue el primer texto que vi en Hacker News. Cada vez que vuelve a aparecer, me trae recuerdos de aquellos tiempos