Faça coisas que não escalam (2013)

 (paulgraham.com)
3 pontos por GN⁺ 2025-08-17 | 1 comentários | Compartilhar no WhatsApp
  • A Y Combinator aconselha que, no início da startup, é preciso fazer ativamente "coisas que não escalam"
  • Startups bem-sucedidas como Stripe e Airbnb escolheram uma abordagem direta e agressiva para conquistar os primeiros usuários
  • A maioria das startups é muito frágil no começo, e o esforço manual dos fundadores é o núcleo do crescimento
  • Oferecer aos primeiros usuários uma experiência excepcional e grande satisfação é importante para o crescimento de longo prazo
  • Na fase inicial, trabalho manual em vez de automação, foco em um nicho e consultoria direta costumam ser eficazes

Introdução: a realidade do crescimento de startups

  • Muitos aspirantes a fundadores pensam que startups crescem sozinhas, mas, na prática, os fundadores precisam agir diretamente para acender a faísca do crescimento
  • Como a manivela de partida dos carros antigos, no começo um processo intensivo em trabalho é indispensável

Recrutar usuários diretamente (Recruit)

  • A maioria das startups não deve esperar passivamente que os usuários apareçam, mas sim sair à procura deles
  • No caso da Stripe, no início eles usaram uma estratégia agressiva de aquisição chamada "Collison installation", em que pegavam diretamente o notebook da pessoa apresentada à versão beta e faziam a instalação
  • Os fundadores evitam esse tipo de trabalho por causa do medo da rejeição, da vergonha e da tendência a subestimar um número pequeno de usuários
  • Na prática, por causa do efeito de crescimento composto, manter apenas 10% de crescimento semanal já pode levar a milhões de usuários após 2 anos
  • A Airbnb também foi tão ativa a ponto de visitar pessoalmente anfitriões em Nova York para ajudá-los a se cadastrar

A fragilidade das startups no início (Fragile)

  • Quase toda startup é muito instável no começo, e esforços diretos de curto prazo podem definir o sucesso ou o fracasso
  • Mais perigoso do que a indiferença de críticos externos ou investidores é você mesmo subestimar o valor do seu negócio
  • No início, em vez de perguntar "essa empresa vai mudar o mundo?", é preciso se perguntar "até onde ela pode crescer se fizermos o esforço certo?"
  • Como exemplo, os primeiros dias de Microsoft e Airbnb pareciam muito modestos por fora, mas ainda assim estavam no melhor caminho possível
  • Os usuários adequados podem ser encontrados entre pessoas parecidas com você, ou identificando, entre os primeiros usuários, o grupo mais entusiasmado e atacando esse segmento com foco

Maximizar a alegria do usuário (Delight)

  • Além de recrutar usuários, é preciso um esforço extraordinário para dar uma satisfação excepcional aos usuários existentes
  • A Wufoo construiu confiança no início com um serviço tão marcante que enviava cartas de agradecimento escritas à mão para cada novo cadastro
  • Em vez de ficar preso ao senso comum do atendimento ao cliente de grandes empresas, vale enfatizar a experiência personalizada que só uma startup no início pode oferecer
  • Se as tarefas para encantar os primeiros usuários ficarem numerosas demais a ponto de parecer difícil dar conta, isso pode ser, na verdade, um sinal positivo de crescimento
  • A falta de experiência dos fundadores com atendimento ao cliente é uma das razões pelas quais eles não aproveitam plenamente a vantagem competitiva exclusiva de uma empresa pequena

Obsessão pela experiência do usuário (Experience)

  • Como na expressão de Steve Jobs, "Insanely great" (absurdamente excelente), no começo é necessário ter obsessão pela experiência do usuário
  • Mais importante do que um produto inicial completamente acabado é melhorá-lo por meio da interação com os usuários, mesmo que ainda esteja incompleto
  • O feedback obtido no contato direto com os usuários tem o maior impacto sobre o crescimento

Começar por um mercado estreito (Fire)

  • Como Facebook e Airbnb, vale usar a estratégia de começar deliberadamente por um mercado muito pequeno (por exemplo, estudantes de Harvard) e atingir massa crítica dentro desse grupo
  • No início, é mais eficaz encontrar o grupo de early adopters que responde mais rápido
  • Programas de aceleração como o YC também ajudam na abordagem de mercado em que outras startups viram clientes

Estratégia especial para startups de hardware (Meraki)

  • Como startups de hardware têm alto custo inicial de produção em massa, fundadores de empresas como Meraki e Pebble montavam os produtos eles mesmos
  • Ao fabricar diretamente, ocorre um aprendizado empírico sobre otimização de projeto, obtenção de componentes e outros pontos

Abordagem extrema de usuários no estilo consultoria (Consult)

  • Em produtos B2B, é possível desenvolver algo sob medida para um cliente específico, como se fosse consultoria, e depois expandir para mercados adjacentes
  • É no processo de se ajustar completamente ao problema que o cliente realmente precisa resolver que surgem pistas para o crescimento
  • No início, também é possível usar o software no lugar do cliente ou refletir imediatamente as funcionalidades necessárias

Estratégia totalmente manual (Manual)

  • Quando o número de usuários é pequeno, é possível processar o trabalho manualmente e depois migrar gradualmente para automação
  • No começo, a Stripe tratava manualmente a "abertura instantânea de conta" para entregar a experiência desejada ao usuário
  • Em vez de se prender à automação desde o primeiro dia, o mais importante é entender os problemas reais do produto e dos clientes por meio do trabalho manual

A ineficiência do "grande lançamento" (Big)

  • Estratégias de fazer um grande lançamento de uma só vez ou deixar o crescimento nas mãos de parcerias com grandes empresas em geral fracassam
  • No início, é preciso focar em conquistar poucos usuários, e esforço intenso e métodos diretos são mais importantes
  • O interesse dos usuários cresce lentamente, por meio de gestão direta e da oferta de satisfação

Abordagem bidimensional para ideias de startup (Vector)

  • Startups que dão certo precisam ser pensadas como um vetor de produto (o que construir) + estratégia não escalável (o que fazer diretamente no começo)
  • Esse tipo de ação direta no início deixa efeitos positivos no DNA do produto
  • O esforço direto inicial acaba se transformando, com o tempo, em produto e cultura organizacional, tornando-se a força motriz de um crescimento duradouro

Leituras relacionadas

1 comentários

 
GN⁺ 2025-08-17
Opiniões do Hacker News

  • Ouvi recentemente algo em um podcast com que me identifiquei muito: o maior problema de uma startup é a inércia. O mundo não gosta muito de nós nem sente que precisa de nós... temos que inverter isso. É preciso criar momentum totalmente do zero, e o trabalho realmente importante do fundador é agir para reverter a inércia. Isso também acontece literalmente na física. O mundo está parado, e nós precisamos criar o momentum com as próprias mãos, como ao ligar um motor pela primeira vez. Vendo por esse ângulo, não é estranho fazer coisas que não escalam no começo. Você não está otimizando uma máquina que já está rodando; está numa fase em que precisa girar peça por peça até o motor começar a funcionar direito. O ponto do Paul Graham é que crescimento escalável ou automação vêm depois. Ao abordar tudo manualmente e encontrar os usuários um por um, você aprende de verdade o que funciona. É um processo de acumular evidências de que os usuários veem valor real em você e provar o que vale a pena escalar

    • Para mim, o verdadeiro valor do trabalho manual é o aprendizado direto. Um dos meus clientes fornecia uma lista curada de notícias financeiras e do mercado de capitais, selecionadas manualmente toda semana. Era um nicho dentro de outro nicho menor ainda, mas os usuários adoravam. Em certo momento, tentou automatizar tudo, e o conteúdo passou a ficar excessivo e menos seletivo, com mais informações de baixa qualidade, então o valor desapareceu e o produto seguiu o mesmo caminho. Passou a incluir mais notícias, mas, sem curadoria e edição manuais, a proporção entre sinal e ruído piorou. Na prática, o trabalho manual, embora limitado em escopo, era muito mais valioso. Muitas empresas não entendem isso e ficam obcecadas cedo demais por automação. Outro exemplo: um cliente verificava manualmente os preços dos concorrentes. Quis automatizar, então criamos um scraper simples baseado em Excel. No início ele ficou satisfeito, mas depois percebeu que, ao deixar de explorar diretamente os sites dos concorrentes, estava perdendo a chance de aprender sobre novos produtos, tendências de catálogo etc. No fim, voltou a explorar manualmente e passou a usar o scraper só para análise simples de preços. Mas a maioria dos meus outros clientes continua focando apenas em automação, em vez da essência do produto e do problema, e segue perdendo oportunidades importantes de aprendizado

    • É por isso que “faça algo que as pessoas queiram” virou uma máxima no mundo das startups

    • Gostei muito da expressão “reverter a inércia”, mas essa abordagem não se aplica a toda startup. Segundo o framework Arc da Sequoia, há três formas: Hair on Fire (dor urgente, em que momentum importa), Hard Fact (há dor, mas é preciso mudar hábitos) e Future Vision (as pessoas ainda nem acreditam que isso seja possível, então primeiro é preciso construir confiança). Obter resultados fazendo manualmente coisas que não escalam é essencial em áreas Hair on Fire, mas nas outras é mais uma questão de reconstruir a própria realidade ou estabelecer credibilidade antes

  • Minha teoria divide isso em três fases: Not Scaling, Scaling e Antiscaling. Not Scaling é a fase de construir seu próprio moat no mercado. Scaling é quando o produto se torna popular o suficiente para que clientes tragam novos clientes, e basta lidar com o aumento da demanda dividindo servidores ou bancos de dados. Antiscaling é quando a empresa vira algo parecido com os problemas da web moderna. Agências de inteligência entram em contato por causa do uso por terroristas, prefeitura ou governo criam diretamente licenças ou leis regulatórias mirando você, e o fundador se torna tão conhecido que vira meme e até rastreável. Não é preciso dominar o mundo, basta ganhar dinheiro. Raramente quem sai dizendo que vai mudar o mundo produz de fato bons resultados, então o importante é simplesmente criar algo útil

    • Essa ideia de “basta ganhar dinheiro” me lembra a Goodhart’s Law: quando uma métrica, como receita, vira objetivo, ela deixa de ser uma boa medida

    • Essa visão me parece enviesada demais. Ela não trata da indiferença extrema que acontece quando você cria algo que ninguém quer. E, na verdade, o caso mais comum é outro: um sucesso bem mediano. Ninguém odeia, mas também ninguém ama loucamente. Há uma reação levemente positiva, mas sem hype nem vantagem competitiva exclusiva, e no fim ninguém liga muito

  • Estou deixando os links abaixo porque queria reunir mais casos relacionados

  • Quero compartilhar isso como algo que eu recomendaria a todo fundador em estágio inicial e também a todo funcionário que entrou cedo na empresa. Já passamos de 15 pessoas e ainda assim ligamos pessoalmente para cada novo cadastro. Fazemos isso para 1) entender como a pessoa nos conheceu 2) saber se precisa de ajuda para começar a usar 3) transmitir, ainda que implicitamente, que nosso time realmente se importa. Nosso serviço é uma plataforma B2B, então talvez funcione ainda melhor por isso, e mesmo sendo voltado a desenvolvedores, quando você faz a ligação e passa da parte do “não, não estamos tentando te vender nada”, surgem muitas conversas francas e valiosas

  • Há muita gente criticando Paul Graham, mas este texto em si pode ser resumido como um alerta contra otimização prematura. Em outras palavras, não aja como uma empresa grande. Quando o fundador faz o trabalho operacional diretamente, mesmo que seja ineficiente, acumula experiência prática e feedback, e ao não adotar cedo demais uma solução escalável, consegue receber feedback mais rápido. Além disso, isso também ajuda a criar diferenciação. Acho que vale a pena gravar literalmente na cabeça a frase “faça coisas que não escalam”

    • Muitas vezes se constrói, cedo demais, um sistema exageradamente escalável por medo de que o serviço não aguente uma popularidade ou demanda excessiva, mesmo quando não há necessidade real disso. E eu sinto que escalabilidade vertical, no sentido de simplesmente adicionar mais recursos, é subestimada demais. Só de colocar mais recursos em um backend monolítico existente, já dá para ganhar tempo para entender melhor o serviço. Mais importante ainda, isso faz você reconsiderar qual é exatamente o “valor central” de que os usuários gostam no seu produto. E, se os usuários realmente amam o produto, eles toleram algum problema de desempenho no começo. No início do Twitter aparecia muito o “fail whale”, mas a empresa cresceu explosivamente porque entregava bem a funcionalidade que as pessoas queriam. No estágio inicial, tudo gira em torno de feedback rápido, iteração e satisfação do cliente. Antes de escalar, vêm experimentação, conversa com usuários e observação. Faz sentido pensar em escalar quando aquele estalo acontecer, e não dá para prever esse momento. Tecnologia é só ferramenta; mesmo com um violino de luxo, antes de tudo é preciso fazer boa música

    • Também é preciso lembrar que nem todo negócio bem-sucedido atende centenas de milhões ou bilhões de usuários. Eu trabalho criando ferramentas internas, e o tamanho do nosso ambiente já é conhecido, não somos muito sensíveis a performance e não há tráfego irregular. Mesmo assim, tivemos um colega obcecado em reescrever todo o código em uma linguagem que só ele conhecia para economizar alguns milissegundos. Ninguém ligava para isso, e o que ele construiu só deixou risco de manutenção. Quando saiu da empresa, por decisão da gestão, tudo foi descartado; se o design tivesse sido mais simples e um pouco mais lento, teria sido muito mais fácil para outras pessoas assumirem depois

    • “Otimização prematura” e “Do Things That Don’t Scale” são sutilmente diferentes. A primeira pressupõe que a versão escalável é a “ótima”, enquanto a segunda sugere que a forma não escalável pode até ser a melhor. Por exemplo, o CEO cuidar pessoalmente dos contatos pode ser muito melhor do que uma caixa de entrada compartilhada que trata tudo. A forma escalável, como um formulário de contato, não é uma otimização desde o início; na prática, ela pode representar uma piora na qualidade do processo. Escalar em si não é um mal, mas traz inevitavelmente complexidade e distância do cliente. É preciso reconhecer que, dependendo da situação, o processo pode piorar. Para mim, a mensagem está mais próxima de “evite degradação prematura do processo”

    • No fim, isso pode ser resumido como “não tente resolver antecipadamente problemas que ainda não existem”

    • O conselho “não aja como uma empresa grande” honestamente se aplica a organizações de qualquer tamanho. Como consultor, eu gasto muito tempo impedindo startups e pequenas empresas de tentarem adotar regras e políticas de organizações enormes só porque são pessoas jurídicas. Essas políticas só fazem sentido em empresas com centenas de pessoas, e em estruturas pequenas acabam mais atrapalhando do que ajudando. Exemplos: k8s, NoSQL, políticas de segurança rígidas além da conta. O guia de cultura interna da Netflix mostra isso muito bem. Em organizações pequenas, partindo do princípio de que você contratou bem, o ideal é delegar de verdade e deixar que cada integrante da equipe julgue por si. Não há necessidade de engessar tudo em regras até que os problemas ou riscos cresçam de fato

  • A Stripe é uma das empresas de maior sucesso do portfólio da YC, e o problema que ela resolveu era realmente agudo e urgente. Em uma situação em que qualquer um poderia ter ficado esperando os usuários chegarem, a Stripe ficou conhecida justamente por uma aquisição de usuários muito agressiva. Isso foi há 12 anos, e eu não imaginava que ela cresceria tanto. Queria muito ter podido investir naquela época

  • Claro que existe survivor bias. Ainda assim, concordo plenamente com o ponto de que esse período de fazer o trabalho diretamente, sem automatizar, é importante. É assim que você grava na cabeça, com muito mais precisão, o processo ou o sistema como um todo, algo que não dá para obter só com slides ou documentos. Em termos atuais, isso também pode ser chamado de construir “taste”. É a fase em que você desenvolve sensibilidade para o que é bom e por quê, e forma uma visão clara em pontos de decisão que outras pessoas nem chegam a considerar. Hoje, com IA, muitos lugares tentam pular cedo demais para a automação, mas no www.socratify.com também fazemos o conteúdo manualmente. Todo mundo diz que tem que ser feito com IA, mas nosso objetivo principal é justamente fazer curadoria adequada de contexto e qualidade. O processo de validação pode até ser parcialmente automatizado depois, mas na prática temos visto, ainda que indiretamente, como é difícil substituir totalmente o cérebro e a percepção humana

  • A YC mudou o jogo ao tornar o seed funding muito mais acessível. Tenho certeza de que Paul Graham, Jessica Livingston e a equipe da YC entenderam direito os problemas do sistema anterior e os corrigiram. Antes da YC, levantar seed era quase impossível. Era desigual e parecia fazer uma apresentação para oito sócios irritados em um escritório bancário antiquado. Se há mérito a reconhecer, é que foram eles que consertaram esse mercado

    • Acho que essa parte é discutível. Mesmo que o acesso a funding tenha sido aberto a mais gente, na prática levantar rodada seed continuou difícil tanto antes quanto depois da YC. A diferença é que, com o surgimento de um player grande como a YC, a posição dos fundadores bootstrapper ficou mais fraca. Em algum momento, passou a surgir uma situação em que o fundador não seguia o que realmente queria, mas os temas que a YC escolhia. Diminuiu a oportunidade de o fundador trabalhar em algo em que queria se tornar realmente bom

  • Gostaria que empresas grandes como a OpenAI lessem “Do Things That Don’t Scale” com seriedade e realmente levassem isso em conta. Com esse nível de capital, elas poderiam muito bem ter comprado legitimamente as licenças de dados necessárias. Mas escolheram apenas o caminho escalável (scraping, stealing) e parecem ter apostado que, mesmo pegando muita coisa emprestada sem autorização, ninguém perceberia, ou que as contestações só chegariam tarde demais. Em outras palavras, esperavam que passasse despercebido o fato de que os criadores de conteúdo de hoje não receberam um centavo por terem seu trabalho usado como dados de treinamento de IA sem saber

    • Isso me parece menos um problema de escalabilidade e mais algo ligado à ganância inevitável de “não querer gastar dinheiro” no capitalismo

  • Este foi o primeiro texto que vi no Hacker News. Sempre que ele reaparece de vez em quando, traz de volta uma certa nostalgia