O founder como jardineiro: arquitetar ecossistema em vez de ditar resultado
Existe uma pergunta que separa founders de web2 e de web3 melhor que qualquer teste: "o que você controla no seu projeto?". O founder de software tradicional responde com roadmap, backlog e metas trimestrais. O founder de web3 que entendeu o jogo responde com outra lista: incentivos, governança, cultura e ferramentas. Ele não controla o resultado. Controla as condições.
Essa não é uma frase de efeito, é uma mudança operacional documentada. No guia de go-to-market em web3 da a16z, Alex Zhang, à frente do Friends with Benefits, descreve o próprio trabalho de forma reveladora: a função dele não é estabelecer uma visão de cima para baixo, e sim criar frameworks para os membros da comunidade, curando o ambiente como quem cuida de um bairro, desativando canais sem tração e apoiando os que têm momentum.
A melhor imagem para isso é a estufa. O jardineiro não fabrica a planta. Ele controla solo, luz, água e temperatura, escolhe o que plantar, poda o que cresce torto e protege contra pragas. O fruto é consequência das condições, não de uma ordem. Em web3, onde o produto é uma rede de pessoas com incentivos econômicos, o founder que tenta fabricar o fruto diretamente costuma matar a planta.
Principais takeaways
Continue por dentro
Um estudo denso por quinzena, direto no seu email.
Os bastidores de por que tokens e projetos crescem. Sem ruído, sem spam.
- Em web3, o founder migra de planejador top-down para arquiteto de condições: propósito, incentivos, governança e ferramentas.
- A comunidade produz valor emergente que nenhum roadmap prevê, mas só quando as condições estão desenhadas para isso.
- O jardineiro continua tomando as decisões mais importantes: o que plantar, o que podar, o que proteger.
- Incentivo é clima: o caso Compound mostra tokenomics resolvendo cold start ao transformar recompensa em condição de crescimento.
- Métricas de saúde do ecossistema substituem métricas de comando: contribuição espontânea, retenção de contribuidores, integrações e forks.
Por que o modelo de comando quebra em web3
O founder de web2 opera uma máquina: contrata, prioriza, entrega, mede. Funciona porque todos os atores da execução são funcionários, e funcionário responde a comando. Em web3, a maior parte dos atores que geram valor não é contratada: são holders, contribuidores voluntários, desenvolvedores de integrações, criadores de conteúdo, delegados de governança. Ninguém deles aceita ordem. Todos eles respondem a incentivo.
Quando o founder tenta aplicar o playbook de comando nesse contexto, três falhas aparecem em sequência. Primeiro, a comunidade vira audiência: espera instrução em vez de criar, porque aprendeu que iniciativa própria não tem espaço. Segundo, os melhores contribuidores vão embora, porque contribuidor de alto nível procura agência, não tarefa. Terceiro, o projeto fica limitado à capacidade de execução do time central, que é exatamente a limitação que o modelo de rede existia para superar.
O guia da a16z resume a alternativa em três condições: propósito claro, comunidade engajada e governança compatível com a organização. Repare que nenhuma das três é um resultado. Todas são condições de cultivo.
As quatro camadas da estufa
A metáfora vira método quando se decompõe o que, exatamente, o founder-jardineiro controla. São quatro camadas, e cada uma tem equivalente direto no cultivo.
| Camada da estufa | Equivalente no projeto | O que o founder decide |
|---|
| Solo | Propósito e narrativa | Por que o projeto existe e o que nunca será |
| Clima | Incentivos e tokenomics | O que é recompensado, quanto e por quanto tempo |
| Estrutura | Governança e processos | Quem decide o quê e como conflitos se resolvem |
| Ferramentas | Infraestrutura e acesso | O que a comunidade consegue construir sozinha |
O clima é onde a maioria dos erros acontece. Incentivo é uma força cega: recompensa o comportamento que mede, não o que o founder queria dizer. Se o programa premia volume de transação, atrai quem fabrica transação. O caso clássico documentado pela a16z é o do Compound, que usou liquidity mining para resolver o problema de cold start: com as recompensas em COMP, o valor total depositado no protocolo saltou de cerca de US$ 100 milhões para cerca de US$ 600 milhões após o lançamento do programa em 2020, segundo o mesmo artigo da a16z. O incentivo funcionou como clima: não ordenou que ninguém depositasse, tornou o depósito a coisa natural a fazer.
A estrutura define como o poder circula. Governança pesada demais paralisa; leve demais, vira capturável. E as ferramentas definem o teto da emergência: comunidade sem acesso a tesouraria, dados e infraestrutura só consegue produzir opinião.
O que o jardineiro faz o dia inteiro
A objeção comum ao modelo é que ele soa passivo, como se o founder plantasse e esperasse. A prática é o oposto: o jardineiro trabalha o tempo todo, mas em atividades diferentes das do gerente.
Observação constante. O trabalho de Zhang no Friends with Benefits, como descrito no artigo da a16z, é essencialmente curadoria: olhar o que tem tração e o que não tem, e realocar energia. Isso exige presença diária na comunidade, não relatório mensal.
Poda decisiva. Iniciativas que não vingam consomem atenção, orçamento e moral. Desativar um canal morto, encerrar um programa que não funcionou e comunicar o porquê é das funções mais importantes do founder, e das mais evitadas, porque poda dói.
Proteção do propósito. Todo ecossistema com valor atrai oportunismo. O jardineiro remove a praga cedo: o contribuidor tóxico, o incentivo capturado, a proposta de governança que beneficia um grupo às custas do todo. Esperar a comunidade se autorregular em casos assim é abdicação, não descentralização.
Replantio deliberado. Quando uma área do ecossistema precisa existir e não nasceu sozinha, o founder planta: financia o primeiro time, recruta o primeiro contribuidor, constrói a primeira versão. A diferença para o modelo de comando é que ele planta para soltar, não para operar para sempre.
Como medir um jardim
Métricas de comando (entregas do roadmap, metas de output do time central) continuam existindo para o núcleo do projeto, mas não medem a saúde do ecossistema. Para isso, a régua muda de output para emergência:
- Contribuição espontânea: quantas iniciativas nasceram da comunidade neste trimestre sem pedido do time central, e quantas sobreviveram 90 dias.
- Retenção de contribuidores: quem contribuiu uma vez, contribui de novo? Ecossistema saudável retém gente, não só capital.
- Sinais de rede: o guia da a16z aponta holders únicos, engajamento recorrente, atividade de desenvolvedores e integrações como as métricas que capturam adoção real além do capital depositado.
- Velocidade de resposta do ecossistema: quando surge um problema ou uma oportunidade, a comunidade se mobiliza sozinha ou espera o time central?
A leitura correta dessas métricas é diagnóstica: quando a contribuição espontânea cai, o founder não ordena contribuição, investiga qual condição quebrou. Foi o incentivo que envelheceu? A governança que emperrou? A ferramenta que falta?
Os três erros de jardinagem mais comuns
Excesso de água. Despejar incentivo demais, cedo demais. Comunidade regada a token antes de ter propósito enraizado cresce rápido e apodrece rápido: atrai mercenário, infla métrica e colapsa quando a torneira fecha.
Medo da poda. Manter programas, canais e parcerias mortas por medo de sinalizar fraqueza. O resultado é um jardim cheio de mato onde ninguém encontra o que importa. Ecossistemas fortes são visivelmente editados.
Replantio compulsivo. Mudar tokenomics, governança e narrativa a cada trimestre. Planta não cresce em solo que é revirado toda semana. Condições precisam de estabilidade para que a comunidade construa em cima delas com confiança.
Conclusão
O founder-jardineiro não é um founder que faz menos. É um founder que atua em outra camada: escolhe o que plantar, desenha solo, clima, estrutura e ferramentas, poda sem dó e protege o propósito. O resultado que ele colhe é maior do que qualquer roadmap conseguiria ditar, precisamente porque não foi ditado.
A Kaleidos trabalha com essa lente em projetos web3: transformar visão de founder em arquitetura de condições, com narrativa, incentivos e comunidade desenhados como sistema. É essa a abordagem aplicada nos projetos que a agência atende. Se o seu projeto cresce menos do que a comunidade dele permitiria, fale com a Kaleidos.
