Hacer Cosas Que No Escalen

Alberto Samaniego
The Product Lab
Published in
4 min readMay 28, 2020

Hace poco volví a leer un artículo donde Paul Graham habla de por qué al comienzo los fundadores de una startup tienen que hacer cosas que no escalen. Me pareció que vale la pena hacer un resumen en español para aquellas personas que no hablan inglés.

Además agregué algunos ejemplos y conceptos de otras fuentes que no se mencionan en el artículo original, pero que de alguna manera están relacionados con el tema (así que es un resumen con mis puntos de vista).

En el artículo, Paul Graham hace referencia a las startups, pero particularmente creo que el enfoque puede aplicarse a cualquier emprendimiento nuevo de software, sea o no una startup.

El artículo original es este.

Cosas que no escalan

Una de las principales recomendaciones que da Paul Graham a las startups en fase inicial es hacer cosas que no escalan. Eso podría implicar, por ejemplo, que contactes directamente con tus usuarios para ayudarles a usar tu producto por primera vez.

Podría parecer contraintuitivo. Pero veamos algunos ejemplos de quienes comenzaron así:

AirBnB

En una fase inicial, Brian Chesky y Joe Gebbia, ayudaban manualmente a los propietarios a listar y mejorar sus publicaciones en AirBnB en Nueva York.

Stripe

John y Patrick Collison consiguieron sus primeros usuarios preguntando personalmente a otros fundadores si estaban dispuestos a probar Stripe. Cuando estos accedían, ellos se sentaban personalmente a instalarlo y configurarlo en sus computadoras.

Zappos (no está en el artículo original)

Para probar el concepto de vender zapatos en Internet, Nick Swinmurn creó un sitio con un catálogo pero sin tener un inventario real de zapatos. Cada vez que alguien ordenaba un par, Nick iba personalmente comprarlo. Para el usuario ese proceso era transparente, y generaba la ilusión de estar comprando directamente de una tienda online.

¿Por qué esto es importante?

Según Ash Maurya, autor de Running Lean, una startup tiene 3 etapas:

  1. Encontrar la solución adecuada al problema adecuado.
  2. Encontrar el producto adecuado al mercado adecuado.
  3. Escalar.

La meta en las dos primeras etapas es aprender, no escalar de forma masiva.
(Obs.: en el artículo original, Paul Graham no hace referencia a Ash Maurya).

Esto me parece súper importante de tener presente. La mayoría de las veces, lo primero que piensan quienes están comenzando con una idea de una app es en cómo volverse viral, saltándose de las dos primeras etapas directamente a la tercera.

La meta no es construir el producto más hermoso y perfecto, sino poner algo frente a los usuarios lo antes posible para tener un aprendizaje validado, y a partir de ahí, gradualmente (y velozmente) ir perfeccionando el producto.

Hacer cosas que no escalen, es una de las mejores maneras de aprender. Y según Paul Graham, involucrarse de forma excesiva con los primeros usuarios no solo es permisible, sino que es NECESARIO en una primera etapa.

Las dos cosas más comunes

Las dos cosas más comunes que no escalan y que por lo general hay que hacer son:

  • Conseguir usuarios manualmente.
  • Brindar una experiencia extraordinaria a esos primeros usuarios.

Conseguir usuarios manualmente

Una de las formas más fáciles de conseguir usuarios manualmente se da cuando el producto resuelve un problema que uno mismo tiene. En ese caso, uno simplemente tiene que encontrar a otras personas como él o ella misma, que tengan el mismo problema. Por lo general, estas personas estarán entre los contactos directos.

La otra manera requiere hacer un poco más de esfuerzo para encontrar a los usuarios más prometedores (los “early adopters”). Este enfoque consiste en hacer un lanzamiento más genérico, y a partir de ahí ver qué tipo de usuarios muestra más interés y entusiasmo en lo que estás construyendo.

El ejemplo que da aquí Paul Graham es el de Pinterest. Ben Silbermann, el fundador de Pinterest, notó que muchos de sus primeros usuarios tenían interés en el diseño. Habiendo observado esto, Ben decidió ir personalmente a conferencias de bloggers de diseño a tratar de conseguir usuarios.

Brindar una experiencia extraordinaria

“No es tu producto el que tiene que ser extraordinario, sino la experiencia que das a tu usuario”, menciona Paul Graham en su artículo.

En una empresa ya establecida, gran parte de la experiencia gira -por supuesto- en torno al producto. Pero en un emprendimiento en fases iniciales, la falta de un gran producto se puede suplir con una atención excesivamente buena a los usuarios.

Esto es así porque los primeros usuarios de tu producto -los early adopters- sienten una necesidad intensa de resolver el problema que les estás resolviendo. Y eso hace que estén mucho más dispuestos a dar feedback, tolerar errores y utilizar un producto que aún está incompleto.

Hacer un esfuerzo extraordinario para prestar atención a esos usuarios, te dará un aprendizaje que de otra manera no podrías obtener.

¿Vale la pena?

Todo esto puede parecer no solo mucho trabajo, sino además inconsecuente o insignificante. ¿Por qué hacer tanto esfuerzo solo por unos pocos usuarios?

El mejor aprendizaje se da con el contacto directo. Puede parecer tentador hacer encuestas en lugar de hablar directamente con los usuarios ya que podrías alcanzar a más personas. Pero realizar encuestas supone que ya sabés de antemano cuáles son las preguntas correctas a hacer. Además, tener contacto directo te permite no solo escuchar al usuario, sino también observar cómo se comporta.

El contacto directo permite descubrir lo inesperado, aquello que no sabías que no sabías. Y por lo general, ahí es donde está el aprendizaje más valioso.

Para terminar, voy a mencionar una cosa más que Paul Graham dice en el artículo, y eso es que no se puede juzgar a una startup con los mismos parámetros que a una empresa establecida. Así que por el momento olvidate de las comparaciones con otras empresas que ya son exitosas, y enfocate en lo que más importa en esta etapa: conseguir usuarios y brindar una experiencia extraordinaria haciendo cosas que no escalen.

Si entendés inglés, te recomiendo leer el artículo original (bastante más extenso) aquí: http://paulgraham.com/ds.html

--

--