O founder como jardineiro: arquitetar ecossistema em vez de ditar resultado

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

• 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.

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?

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.