Cinco especialistas que não existem revisam sua startup antes de você criá-la

Em novembro de 2024, um projeto chamado Freysa colocou um agente LLM para proteger uma wallet Ethereum. A instrução era clara: não transfira os fundos sob nenhuma circunstância. Os participantes pagavam valores cada vez mais altos a cada tentativa de convencê-lo. Após 481 tentativas e US$47.000 acumulados no prêmio, alguém conseguiu convencer o modelo de que a função rejeitar era, na verdade, a função transferir.

Algumas semanas depois, a Jane Street publicou um enigma onde uma rede neural de 2.500 camadas revelou-se uma implementação do MD5. O vencedor resolveu isso combinando visualização de matrizes, redução para SAT, reconhecimento de padrões criptográficos e uma consulta ao ChatGPT.

Ambos os projetos chamaram mais atenção do que a maioria das startups que levanta milhões em investimentos. A pergunta é óbvia: como avaliar uma ideia como essa antes de construí-la? Como saber se há potencial viral genuíno ou se é apenas um exercício técnico interessante que ninguém vai compartilhar?

O problema: avaliação de MVPs na era da viralidade

A maioria dos frameworks para avaliar ideias de produto assume um mercado racional. Business Model Canvas, Lean Canvas, Jobs To Be Done — todas são ferramentas valiosas para produtos com demanda previsível. Mas falham com projetos em que a distribuição viral é o próprio produto.

Freysa não tinha “clientes” no sentido tradicional. Não resolvia um “job to be done”. Era um mecanismo onde o próprio ato de participar gerava atenção que atraía mais participantes. A economia era circular: mais tentativas geravam um prêmio maior, um prêmio maior gerava mais cobertura da mídia, mais cobertura atraía mais tentativas.

Para avaliar esse tipo de projeto, você precisa de perspectivas que gerem tensão, não consenso. Um analista de negócios dirá que não há um modelo de receita sustentável. Um especialista em viralidade dirá que a sustentabilidade não importa se o k-factor é maior que 1. Ambos estão certos. E a verdade está em algum ponto entre os dois, emergindo do conflito entre eles.

A ideia: um conselho adversarial de especialistas simulados

Eu projetei uma ferramenta que simula um conselho de cinco especialistas, cada um com um framework de decisão específico e uma jurisdição bem definida. Não são personalidades genéricas com nomes famosos. Cada um aplica regras de decisão específicas que filtram o ruído que um simples olhar genérico não captaria.

O processo tem três fases:

1. Análise independente: cada especialista avalia a ideia sob sua ótica específica, sem ver o que os outros disseram. Isso previne o anclaje (ou viés de ancoragem) — se o especialista de negócios fala primeiro e diz “isso é ótimo”, o de jurídico suaviza suas objeções.
2. Debate adversarial: os especialistas leem as análises uns dos outros e se criticam mutuamente. Com embasamento, e não diplomacia. Máximo de 10 rodadas até consenso ou impasse.
3. Síntese: um plano executável com problemas por área, cronograma e — o mais importante — critérios de desistência (kill criteria): métricas concretas que, se não forem atingidas, significam que o projeto deve ser encerrado.

Os cinco escolhidos (e por que cada um está lá)

Paul Graham — Negócios e estratégia

Seu framework para avaliar startups na fase zero é o mais rigoroso que existe para projetos sem dados. Sua pergunta “você está fazendo algo que as pessoas realmente querem?” é brutal, mas necessária. Ele não aceita “as pessoas” como um mercado — exige nome e sobrenome do primeiro usuário.

O que ele traz ao conselho: a disciplina de separar uma “ideia interessante” de um “negócio viável”. Seu conceito de “faça coisas que não escalam” é especialmente valioso para MVPs virais, onde a tentação é construir uma infraestrutura para milhões de usuários que ainda não existem.

Descartados para esta cadeira: Peter Thiel (contrarian demais — às vezes rejeita bons projetos por não serem ambiciosos o suficiente para um “zero to one”), Alex Hormozi (sua expertise é em negócios de serviços, não produtos tech virais).

Lawrence Lessig — Jurídico e regulamentação

Ele não é o típico advogado que diz “não pode”. É um jurista que pensa na regulamentação como arquitetura. Seu framework das “quatro modalidades de regulação” (lei, normas sociais, mercado e código/arquitetura) permite analisar como criar um sistema onde a regulamentação não seja um problema, ao invés de tentar evitá-la.

O que ele traz ao conselho: a pergunta “o que acontece quando o regulador percebe que você existe?” Muitos projetos em crypto/IA não são relevantes para a regulação quando pequenos, mas tornam-se quando crescem. Lessig identifica a linha onde a regulamentação entra em cena.

Descartados para esta cadeira: um advogado corporativo genérico (dirá “não” para tudo e matará o projeto antes mesmo de começar). A chave é que Lessig entende que a regulamentação não é o único mecanismo — a arquitetura do sistema pode tornar desnecessária a intervenção legal.

Seth Godin — Marketing e posicionamento

Sua pergunta central — “quem é seu menor público viável e por que isso importa para eles?” — é a mais importante para um lançamento viral. Ele não pensa em “como alcançar milhões”, mas em “como alcançar os primeiros 100 que realmente se importam”.

O que ele traz ao conselho: o teste de “notável”. Isso tem algo que faz alguém compartilhar espontaneamente? “É útil” não é compartilhado. “É notável”, sim. Seu conceito de “Tribes” combina perfeitamente com comunidades tech/crypto que já possuem uma identidade de grupo.

Descartados para esta cadeira: Philip Kotler (corporativo demais — pensa em marketing para multinacionais, não para MVPs), April Dunford (seu framework de posicionamento é excelente, mas projetado para produtos existentes que precisam se reposicionar, não para lançamentos do zero).

Balaji Srinivasan — Hype e viralidade

Este é o conselheiro mais agressivo do painel. Ele entende os mecanismos de distribuição nativos de crypto: FOMO, incentivos tokenizados, efeitos de rede e a mecânica específica de como algo vai de zero a trending em 48 horas.

O que ele traz ao conselho: a pergunta “o que faz alguém tirar um print disso e postar no Twitter nos próximos 5 minutos?” É a unidade atômica da viralidade. Se seu produto não gera prints espontâneos, você precisa de orçamento de marketing.

Descartados para esta cadeira: GaryVee (entende atenção, mas não a interseção crypto+IA, onde os mecanismos de viralidade mais potentes estão hoje), Mr. Beast (sua expertise é em viralidade de conteúdo audiovisual, não produtos tech), Nir Eyal (seu framework “Hooked” é projetado para retenção, não para viralidade de lançamento — são problemas diferentes).

DHH (David Heinemeier Hansson) — Técnico

Sua obsessão é “a coisa mais simples que funciona”. Para um MVP, o maior risco técnico não é usar a tecnologia errada, mas nunca lançar porque você passou três meses escolhendo o stack.

O que ele traz ao conselho: a pergunta “uma pessoa consegue construir isso em 2 semanas?” Se a resposta for não, ou o escopo é muito grande, ou o stack é muito complexo. Sua regra de “tecnologia chata” (PostgreSQL, não CockroachDB; Redis, não Dragonfly) é o antídoto contra o impulso de “usar blockchain porque podemos”.

Descartados para esta cadeira: Werner Vogels (pensa em escala desde o dia 1, o que é exatamente o que não se precisa em um MVP), Kelsey Hightower (sua expertise em Kubernetes superengenharia qualquer MVP — é matar moscas a tiro de canhão).

As tensões produtivas: onde surge a verdade

Os conflitos entre conselheiros não são um defeito do design. São o design.

Balaji vs. Lessig: viralidade contra regulamentação

Essa é a principal tensão. Balaji vai querer mecanismos de FOMO com dinheiro real (prêmios visíveis, pay-to-play, tokens). Lessig apontará que na UE, pay-to-play com prêmio acumulado é enquadrado como jogo de azar e requer licença da DGOJ.

A resolução produtiva não é que um ganhe. É que surja um design que satisfaça ambos: por exemplo, desafios gratuitos com patrocinadores que fornecem o prêmio (legal na maioria das jurisdições), em vez de taxas de entrada diretas (jogo de azar em muitas).

Godin vs. DHH: “notável” contra espartano

Godin quer uma experiência memorável — um leaderboard público com animações, perfis de participantes, badges de conquista. DHH quer uma página estática com SQLite e um formulário.

A resolução: é possível ser “notável” com tecnologia básica? A resposta quase sempre é sim. O conteúdo do desafio é o que impressiona, não a interface. Um leaderboard com uma tabela HTML sem JavaScript pode ser mais impressionante que um painel cheio de efeitos visuais, se o conteúdo for genuinamente fascinante.

Paul Graham vs. Balaji: unit economics contra crescimento

Paul Graham quer um modelo de receita claro desde o dia 1. Balaji vai argumentar que a distribuição viral É o modelo — primeiro audiência, depois monetização.

Ambos têm precedentes a seu favor. O Instagram não tinha modelo de receita quando chegou a 100 milhões de usuários. Mas para cada Instagram, existem 10.000 projetos que cresceram sem modelo e morreram sem dinheiro.

A resolução geralmente é temporária: primeiro validar a viralidade (apoiando Balaji), mas com um prazo rígido para demonstrar unit economics (reforçando Paul Graham). Os critérios de desistência formalizam esse consenso.

O output mais valioso: critérios de desistência

A maioria dos projetos paralelos morre lentamente. Não há um momento claro de fracasso. O fundador simplesmente para de dedicar tempo porque “apareceram outras prioridades”. Três meses depois, o domínio expira e ninguém percebe.

Os critérios de desistência são o oposto: limites concretos, com prazos definidos, que determinam quando parar.

A regra: se 2 de 3 critérios de desistência não forem atingidos, o projeto é encerrado. Sem exceções. Sem “mais um mês”. Sem “não fizemos marketing suficiente”.

Isso é o que distingue um profissional de um amador. O amador se apaixona pela ideia. O profissional se apaixona pelo resultado. E se o resultado não vier no prazo combinado, ele tem a disciplina de parar e focar sua energia em outra coisa.

Por que simulações, e não pessoas reais?

A objeção óbvia: por que não falar com pessoas reais, em vez de simular especialistas com um LLM?

Três razões.

Disponibilidade. Paul Graham não vai lhe dar 2 horas para analisar seu projeto paralelo. A simulação vai. E mesmo que a simulação não tenha toda a experiência acumulada do original, ela aplica os frameworks publicados com consistência, algo que uma pessoa ocupada não faria.

Adversarialidade honesta. Pessoas reais suavizam suas críticas por educação. Uma simulação configurada para ser adversarial vai ser de verdade. “Seu modelo de receita simplesmente não existe” é uma frase que um investidor pensa, mas não diz na primeira reunião. A simulação diz isso logo na primeira rodada.

Custo marginal zero. Você pode rodar o conselho 5 vezes com variações da mesma ideia e comparar os resultados. Tentar isso com 5 pessoas reais exigiria 25 horas do tempo delas.

As simulações não substituem conselheiros de verdade. Mas permitem que você chegue à conversa com um conselheiro real já tendo eliminado os problemas óbvios. É a diferença entre apresentar um rascunho polido e um impulso inicial totalmente bruto.

O meta-padrão: debate estruturado como ferramenta de decisão

Este design não é exclusivo para MVPs. Já o uso para code review (três especialistas em simplicidade, design e performance) e para design review (quatro especialistas em densidade de informação, usabilidade, produto e interação).

O padrão é sempre o mesmo:

1. Especialistas com jurisdição definida: cada um tem domínio sobre um tema e opina com autoridade. Fora de sua área, não tem voto.
2. Frameworks de decisão explícitos: não é “o que você acha”, mas “o que o seu framework sugere sobre isso”.
3. Tensões planejadas: os conflitos entre especialistas são intencionais — eles são a fonte de informação mais valiosa do processo.
4. Convergência forçada: máximo de N rodadas. Se não houver consenso, o moderador decide e documenta a discordância como risco.
5. Resultado prático: não um ensaio, mas problemas registrados, cronogramas e critérios claros de sucesso/fracasso.

A diferença entre “pedir para um LLM analisar sua ideia” e “pedir para 5 LLMs especializados debaterem sua ideia” não é de grau, mas de natureza. O primeiro gera uma opinião. O segundo cria um mapa de riscos e um plano, onde os pontos cegos de cada visão são expostos pelas demais.

A pergunta que você deveria fazer

Antes de escrever a primeira linha de código do seu próximo projeto, pergunte-se: quem vai lhe dizer que isso é uma má ideia?

Se a resposta for “ninguém, porque não perguntei a ninguém”, você já tem um problema. E se a resposta for “meus amigos, que sempre me apoiam muito”, você tem um problema ainda maior.

O que você precisa não é apoio. É escrutínio estruturado de pessoas (reais ou simuladas) que têm incentivos para encontrar as falhas, e não para reforçar suas ilusões. Cinco perspectivas que se contradizem entre si produzem mais verdade do que uma que apenas diz o que você quer ouvir.

O custo de avaliar uma ideia é uma tarde. O custo de construir uma ideia ruim são meses da sua vida que você nunca terá de volta. A conta é clara.

Relacionado: Se está interessado em como o pensamento adversarial se aplica à debugging de sistemas opacos, Uma rede neural de 2.500 camadas que resulta ser o MD5. E, se deseja ver como o mesmo padrão de conselho funciona aplicado ao code review, Simplify: um conselho Jedi para code review com IA.