Sai dessa vibe errada. Vem ser antiviber

Antes de começar, aviso aos navegantes: esse guia não tem lista das dez ferramentas que vão mudar sua vida. Não tem prompt mágico. Não promete que você vai substituir ninguém do seu time por um agente.

Se foi isso que te trouxe até aqui, desculpa estragar a sua vibe. Tá cheio de guru na sua rede social preferida pra te enganar melhor do que eu.

O que tem aqui é um método. Não é nenhuma grande novidade pra quem vem da área, dá mais trabalho do que as pessoas andam vendendo por aí, mas funciona.

Eu uso todo dia com meus clientes para tocar múltiplos projetos simultaneamente com uma equipe super enxuta, e vou mostrar inteiro, sem esconder nenhuma parte.

No fim desse guia, você vai:

1. Saber separar a vibe errada do uso de IA que dá samba de verdade.
2. Entender onde você está hoje e o que está te travando.
3. Ter um método pra sair daí, com um primeiro sprint pra rodar ainda essa semana.

Quem eu penso que eu sou pra falar assim contigo?

Sou Alexandre Leite e trabalho com produtos e ferramentas digitais há mais de 15 anos. Comecei como PM de startups no Brasil, incluindo ser o primeiro PM da Nibo, e ajudei algumas outras a sair do papel. Sempre fui um cara de muita mão na massa, tentando fazer muito com pouco e no menor tempo possível.

Depois me mudei para fora e cresci de PM a GPM passando por eBay, Farfetch e na Kaizen Gaming. Surfei a onda de ser product builder pra duas startups americanas, já com o método que aplico hoje, e por fim fundei o Colaboratório, um estúdio de produto que usa IA e métodos enxutos pra desafogar a operação dos nossos clientes.

Mas antes de chegar nesses métodos, preciso tirar um peso das suas costas.

Calma, fera

Se você anda com a sensação de que está ficando para trás, não é impressão sua. É só o mercado tentando te vender curso, serviço e ferramenta através do bom e velho FOMO.

Essa máquina tem duas engrenagens:

A primeira é inundar com novidades sem profundidade. Toda semana sai uma ferramenta nova, um modelo novo, um agente que muda tudo. E na mesma hora que sai, já tem expert trazendo o lead perdido em 3 prompts. É tanta coisa que acompanhar vira um trabalho em si, e quem tenta consumir tudo fica com a sensação de estar sempre desatualizado sem ter construído nada.

A segunda é a solução milagrosa pra pegar desavisado. A ferramenta que faz tudo por você. É o post de "RIP CRM", de "o designer morreu", de "esse agente substitui seu time de vendas". Sempre com a mesma estrutura: faz do jeito novo e você se dá bem, não faz e você fica para trás.

Juntas, as duas vendem um suposto atalho pro sucesso. É o malandro saindo de casa, e pra sair negócio só precisa topar com um otário no caminho. Eu chamo isso de vibe errada. Vibe coding, vibe marketing, vibe sales: se for sem profundidade, sem intenção e sem método, é tudo a mesma lorota. Hype pra boi dormir.

E o tenso é que esse argumento, o de que quem não entrar agora vai ficar pra trás, é justamente o que devia ficar pra trás e não morre nunca. É o mesmo pitch de sempre, com uma ferramenta nova no lugar da antiga.

Deixa eu te mostrar um pouco por trás da cortina.

Ninguém está na frente em tudo. Quem parece estar na crista da onda está à frente em uma ou duas coisas e bem mediano no resto, igual todo mundo. Tá assim de gente que monta agente complexo e não sabe vender nada. Tem uma porrada de gente que viraliza falando de IA e nunca colocou nada em produção. Eu mesmo estou na frente em algumas coisas e correndo atrás em várias outras, e tá tudo bem.

Nunca é demais lembrar que o que aparece no feed é o recorte que deu certo, editado para parecer fácil. Fica de fora o resto: o que não deu em nada, o que quebrou, o que foi abandonado no meio.

Isso não quer dizer que não tenha nada acontecendo. Tem muita coisa legal acontecendo, de verdade. Eu construo com IA todo dia, e é o motivo de eu conseguir tocar de seis a dez clientes simultaneamente com duas pessoas. O ponto é outro: você não precisa acompanhar tudo. Precisa acompanhar o que resolve o seu problema.

É aí que fica mais fácil do que parece. Não porque a ferramenta faça por você, mas porque a maior parte do barulho não te diz respeito. Se você escolher a coisa mais importante e fizer essa primeiro, o primeiro resultado aparece rápido. E o primeiro resultado puxa o segundo, que puxa o terceiro. É uma sequência de vitórias pequenas, não um salto.

Esse guia é sobre como montar essa sequência. Continua dando trabalho. Mas no fim você vai saber onde colocar energia e como medir se está indo para algum lugar.

Quem faz essa virada eu chamo de antiviber. Não é quem parou de usar IA. É quem parou de correr atrás do barulho e começou a escolher o que construir.

O caminho das pedras

Eu acredito real oficial que a IA me deu superpoderes.

A IA pode levar qualquer pessoa do zero ao passo 10 em quase qualquer assunto. Isso é verdade, é novo, e em muitos casos resolve um problema inteiro ou pelo menos a parte que importa antes de você precisar entender de verdade daquilo.

O que ela muitas vezes não faz é te levar do 10 ao 50, porque a partir dali o que falta não é só execução, é aquilo que só a experiência de verdade te dá: julgamento.

O problema é que ninguém te avisa onde fica o 10. Você descobre dando com a cara nele, ou ficando preso ali até aprender de verdade sobre o assunto ou achando alguém que te aponte o caminho.

Aqui está o mapa, por área, do jeito que eu vejo na prática.

Desenvolvimento. Até o 10: protótipo que roda, tela bonita, integração simples, script que resolve uma tarefa sua. Depois do 10: o que acontece quando dois usuários fazem a mesma coisa ao mesmo tempo, o que fazer quando a integração cai, quais dados você não pode perder nunca. Nada disso aparece até alguém usar de verdade.

Produto. Até o 10: lista de funcionalidades, fluxo desenhado, especificação bem escrita. Depois do 10: qual dessas funcionalidades alguém pagaria para ter, e como você descobre isso antes de construir todas.

Conteúdo. Até o 10: texto correto, estruturado, sem erro. Depois do 10: ter o que dizer. O modelo escreve bem sobre o que você entende. Sobre o que você não entende, ele escreve bem também, e é aí que dá ruim.

Vendas. Até o 10: lista de leads, mensagem personalizada, sequência montada. Depois do 10: saber com quem você não deveria estar falando. Eu aprendi essa na marra, subindo taxa de conexão de 20% para 75% e ainda assim não fechando nada, porque o filtro de quem eu estava chamando estava largo demais.

Repare no padrão. Em todas as áreas, o que vem depois do 10 é sempre uma decisão, não uma execução. E decisão exige experiência do terreno.

Por isso a frase que resume este guia: a IA multiplica a competência que já existe. E multiplicar por zero dá... zero. Nenhum agente vai substituir um time de vendas, conteúdo, produto ou desenvolvimento de quem não sabe (ou está disposto a aprender) o mínimo de vendas, conteúdo, produto ou desenvolvimento.

A boa notícia é que o mínimo é menor do que parece. Você não precisa virar especialista. Precisa entender o suficiente pra julgar o que a máquina te devolve, e é isso que o resto do guia ensina.

Onde você tá agora?

Antes de qualquer coisa, você precisa se localizar. São quatro perguntas e você responde cada uma em dez segundos. Se gaguejar em alguma resposta, é aí que o guia começa para você.

1. Se você sumisse por uma semana, o que ia parar? Se a resposta é "várias coisas" e você não consegue listar, você ainda não enxerga a sua operação.
2. Quantos minutos por dia a IA recuperou pra você no último mês? Se não sabe, você está usando IA sem medir, que é o mesmo que não usar.
3. O que você automatizou continua funcionando quando você não olha? Se você precisa conferir toda vez, aquilo não é automação, é mais uma tarefa disfarçada.
4. Você consegue explicar por que construiu o que construiu? Não como, por quê. Pra quem, resolvendo o quê, e como você soube que era isso que você precisava.

Dependendo de onde você travou, você pode usar uma parte específica do guia:

• Travou na 1: começa pelo passo 1 do protocolo e não pula nada.
• Travou na 2: você está no lugar mais comum. Vá para a seção do cashback de tempo.
• Travou na 3: seu problema é de caminho, não de ferramenta. Vai pra seção de usar pronto, amarrar ou construir.
• Travou na 4: você provavelmente está construindo coisa demais. O protocolo inteiro serve.

Não tem nota, não tem nível, não tem selo. A única razão de responder isso é saber onde colocar a energia da próxima semana.

As três armadilhas

São três jeitos de errar, e eles parecem opostos entre si. Não são. Nos três, alguém produz sem ter decidido o que queria causar.

A estrutura engessada

Semana inteira em reunião, meses até alguma coisa gerar impacto, e aquela desculpinha que sempre explica tudo: engenharia demora mesmo.

Como reconhecer em você: se o seu ciclo tem duração fixa independente da pergunta que você está respondendo, você está aqui. Cadência que existe para se justificar é processo, não método.

Eu vivi isso por anos, e o pior não era a lentidão. Era a distância entre o que dava para fazer e o que a estrutura permitia.

O fundador iludido

Achar que mais resultado vem de mais produção. Comprar mão de obra barata por volume de horas, dar uma ferramenta de IA para cada pessoa e esperar que tudo saia instantaneamente.

Como reconhecer em você: se o seu ganho de produtividade virou mais tarefa para a mesma pessoa, em vez de trabalho melhor, você está aqui. E se você não consegue dizer qual resultado queria causar neste trimestre sem falar de volume de entrega, também.

Eu vi isso de perto e saí em um mês. Não porque as pessoas fossem ruins, mas porque toda tentativa de aplicar método que não fosse entregar mais morria antes de começar.

O builder barata-tonta

Automatizar o que não conhece, começar cinco coisas, não terminar nenhuma, e nunca colocar nada no ar porque nunca está pronto.

Como reconhecer em você: se você tem mais projeto começado do que projeto em uso, você está aqui. Essa é a minha armadilha pessoal, aliás. Eu sei exatamente onde cada ideia se encaixa e paraliso na hora de executar, porque começo a pensar em tudo que pode dar errado.

Repara que ela é o espelho da vibe errada. Quem faz vibe executando o que não entende. O barata-tonta entende sem executar. Nenhum dos dois chega a lugar nenhum.

O protocolo antivibe: passos 1 a 5

O protocolo tem cinco passos. Não inventei nenhum deles. Isso é experimentação de produto, disciplina que existe há vinte anos, apontada para o seu negócio com IA no meio. Está abandonada porque o mercado decidiu que IA dispensa método.

Passo 1. Mapear o terreno

Antes de abrir qualquer ferramenta, você precisa saber o que acontece hoje. Não o que deveria acontecer. O que acontece.

Como fazer:

• Senta do lado de quem faz o trabalho na mão e vê a pessoa fazer. Não pergunta como funciona, pede pra te mostrar. Ou pergunta como foi da última vez que ela fez aquilo de verdade. O que as pessoas descrevem e o que elas fazem são coisas diferentes, sempre. Quer se aprofundar nisso? A Teresa Torres ensina tudo mastigadinho com o método Continuous Discovery Habits.
• Anota onde a pessoa hesita, onde ela confere duas vezes, onde ela tem um arquivo paralelo que ninguém sabe que existe. É ali que está o problema, não no que está bonitinho no fluxograma.
• Escreve em uma frase: quem tem o problema, o que a pessoa está tentando fazer, e o que atrapalha.

Se você trabalha sozinho, quem faz o trabalho na mão é você, e mesmo assim é importante escrever. Muitas vezes, o que a gente faz no automático é exatamente o que a gente menos enxerga. Passa uma semana anotando quanto tempo cada coisa trava antes de decidir o que automatizar.

Isso evita: começar pela ferramenta. Se a primeira frase da sua conversa interna foi "será que dá pra fazer isso com a ferramenta X?", você já pulou o passo 1.

Passo 2. Priorizar o problema e o patamar

São duas decisões, e quase todo mundo toma só a primeira.

O que resolver primeiro. Não necessariamente vai ser o mais fácil de automatizar, nem o mais irritante. Eu prefiro começar pelo que bloqueia mais coisa depois dele. Geralmente é aquele ponto onde alguém espera outra pessoa, ou onde enrolar pra fazer uma atividade mais chata causa mais atraso encadeado.

Até onde ir. Usar algo pronto, amarrar soluções ou construir do zero. Mais pra frente tem uma matriz pra decidir, e o resumo é: escolhe pelo critério, não pelo que parece mais sério.

Isso evita: automatizar o que é fácil de automatizar só porque é fácil, e assumir que a resposta certa é sempre a mais cara. Quando o problema é comum, usar algo pronto quase sempre devolve mais tempo por hora investida do que construir.

Passo 3. O menor experimento que responde a pergunta

A gente não tá buscando a velocidade pela velocidade. Você quer o caminho mais curto até uma evidência em que dê pra confiar.

Como fazer: escreve a pergunta principal que precisa estar respondida antes de começar. E ela quase sempre é um par:

• O problema que eu mapeei é real e do tamanho que eu acho? Como eu provo isso? Os passos 1 e 2 te deram uma aposta, não uma prova. Não vale "as pessoas reclamam". Vale alguém perdendo tempo que dá pra medir, pagando por uma solução pior, ou mantendo uma planilha paralela que ninguém pediu. E às vezes a prova definitiva só chega no passo 4, quando alguém usa: aqui você responde se vale apostar, lá você confirma se a aposta pagou.
• Eu consigo resolver com custo e tempo aceitáveis? Aqui entra a dúvida técnica, tipo "consigo extrair os dados dessa foto com precisão aceitável?".

Responder só a segunda é o jeito mais comum de construir muito bem uma coisa que ninguém precisava. Responder só a primeira é ficar no diagnóstico para sempre.

"Vou construir o sistema de faturamento" não é pergunta. "Esse time leva quatro dias entre o atendimento e o envio da guia, e consigo cortar isso com uma foto tirada no celular?" é. A parte técnica às vezes você responde numa tarde. A do problema às vezes pede uma semana de conversa. As duas mudam tudo que vem depois.

O ciclo dura o que a pergunta exigir. Às vezes é uma tarde com ferramenta open source só para saber se aquilo é possível. Às vezes é uma semana para produtizar em torno do que funcionou e colocar na mão de alguém. As duas coisas são ciclos legítimos, e o erro é tratar as duas com a mesma duração só porque a agenda diz que a sprint é de duas semanas.

Isso evita: o piloto eterno e o "ainda não está pronto". Os dois são a mesma coisa vista de ângulos diferentes: medo de descobrir a resposta.

Passo 4. Testar na mão de quem usa

Toda etapa termina com alguma coisa em uso real. Não em apresentação, não em vídeo, não em ambiente de teste com dado inventado.

Como fazer: entregue a versão feia que funciona para uma pessoa só, de preferência a mais crítica. Fique do lado enquanto ela usa a primeira vez. Anote o que ela tentou fazer que você não previu, porque é isso, e não a opinião dela, que vale.

É o passo que mais gente pula, e é o único que produz evidência de verdade.

O Itamar Gilad, que foi PM no Google, tem uma ferramenta que eu uso muito para explicar isso: o Confidence Meter, um medidor de confiança. Ele organiza os tipos de evidência numa escala de 0 a 10, e a escala é logarítmica de propósito. Lá embaixo, perto de zero, fica a sua convicção pessoal, a ideia que parece alinhada com a tendência do mercado e a opinião dos colegas. Um pouco acima, estimativas e planos, e depois o pedido avulso de um ou outro cliente. No meio, dados de mercado, entrevistas, testes de usabilidade. Só no topo aparece o que vem de gente usando de verdade: testes com usuário real e, por fim, o resultado de um lançamento.

Ou seja: tudo que você tem antes do passo 4 é hipótese. Boa ou ruim, é hipótese.

Mas cuidado com a conclusão errada. Isso não é desculpa para pular direto para a construção e deixar o uso decidir. Os passos 1, 2 e 3 são o que define qual hipótese vale a pena testar, e principalmente o que você está tentando alcançar. Sem isso, o uso real vira um monte de dado sem pergunta, e você não tem como saber se deu certo, porque nunca decidiu o que era dar certo.

Isso evita: a demo de teatro. A demo é construída para impressionar quem assiste. O uso real é construído para servir a quem usa. Não dá para fazer as duas coisas no mesmo artefato.

Passo 5. Iterar com o resultado em ciclos curtos e repetitivos

O que você aprender a partir do uso real decide o que vai rolar no próximo ciclo. Não é o roadmap, não é a sua ideia da semana passada, não é o que a ferramenta nova permite fazer agora.

Como fazer: antes de começar o ciclo seguinte, responda duas coisas: o que mudou de verdade na vida de quem usa, e o que você descobriu que não sabia. Se as duas respostas forem vagas, não avance. Volte ao passo 1 no mesmo lugar.

Isso evita: o projeto de transformação de um ano. Aquela construção eterna que finge que tá diminuindo o risco, mas que na real não consegue nem sair do papel e agora tá todo mundo construindo há tempo demais pra voltar atrás.

A pergunta que atravessa os cinco passos

Você terminou mais capaz do que começou?

Se tem gente trabalhando com você, vale para elas também. É o que separa trabalhar com método de trabalhar com expectativa mágica. Nos dois casos, tem pouca gente e IA no meio. Só em um deles alguém aprendeu de verdade. No outro alguém se esgotou sem aprender nada, porque ninguém estava procurando uma resposta, só aumentando o volume de serviço.

Se no fim do ciclo o sistema melhorou e ninguém entendeu por quê, você não desvibezou nada. Só produziu mais rápido, com o risco de ter produzido errado.

Usar pronto, amarrar ou construir?

Toda vez que você decide resolver algum problema, você está tomando uma decisão de construir ou comprar, mesmo sem chamar assim. E tem três caminhos possíveis, não dois:

• Usar o que existe pronto. Os conectores que já vêm no Claude ou no ChatGPT, o que o seu e-mail e o seu calendário já fazem, a ferramenta de mercado que resolve o caso comum.
• Amarrar soluções. Juntar ferramentas que já existem com n8n, um harness, um agente configurado, integrações entre APIs. Você não constrói as peças, constrói a costura.
• Construir do zero. Software feito pro seu caso, com as suas regras.

A decisão não é necessariamente uma escada. Você não precisa passar pelo primeiro degrau pra chegar no terceiro, e tem empresa que precisa de sistema próprio desde o dia um. É uma decisão, e decisão se toma por critério, não por preferência.

A matriz

Eu costumo organizar em dez critérios, divididos em dois grupos: o que diz respeito ao problema em si, e o que diz respeito ao entorno dele.

Sobre o problema

Sobre o entorno

Como usar esses critérios

Não tem fórmula, não é média. Na real, é mais uma checklist pra você pensar.

Um critério forte sozinho já pode ser suficiente pra você decidir. Se o custo do erro é alto ou a complexidade é alta, isso pode empurrar pra construir mesmo que todo o resto aponte pra usar algo pronto. Por exemplo, um processo fiscal com várias fontes de dado não vai necessariamente virar um conector só porque acontece uma vez por mês.

A estabilidade funciona ao contrário: se o processo ainda está mudando, construir tudo do zero é apostar numa versão que não vai durar. Aí o caminho é construir pequeno, só o pedaço que é crítico, e deixar o resto em um serviço pronto ou amarrado até o processo assentar.

A parte do entorno costuma decidir mais do que o problema, e é o que as pessoas menos olham. Dado regulado passando por uma ferramenta que você não controla é um risco que nenhum ganho de tempo paga. Processo que precisa mudar toda semana, preso numa ferramenta de mercado, te deixa esperando o roadmap de outra empresa. Fonte sem API transforma qualquer amarração em gambiarra. E se não tem ninguém pra manter, amarrar é pior do que parece: a manutenção existe, só fica escondida até o dia em que quebra.

O que cada caminho compra

Usar pronto compra velocidade. É o que devolve mais minutos por hora investida, e não tem manutenção sua.

Amarrar compra flexibilidade. Roda sem você, e dá pra trocar uma peça sem refazer o resto. Não é tão confiável quanto uma coisa própria, e cobra manutenção: coisa amarrada quebra quando a ferramenta do outro lado muda, e alguém precisa ser dono disso.

Construir compra controle. E a possibilidade de fazer o que não existe pronto. Cobra tempo, custo e um dono de verdade, pra sempre.

Os dois erros

São simétricos, e os dois são vibe errada:

• Construir sistema próprio pra uma coisa que um conector resolvia, porque construir parece mais sério. Tipo gastar R$ 10 mil pra desenvolver um sistema só pra economizar R$ 1.000 de assinatura em um ano.
• Sustentar processo crítico numa gambiarra porque "tá funcionando". Funciona até o dia em que falha calada.

O pronto como instrumento de teste

Tem um uso do pronto e do amarrado que vale mesmo quando o destino é construir: responder a pergunta do passo 3. Uma versão tosca montada numa tarde, só pra saber se o problema se sustenta e se dá pra resolver.

Só não confunde prova de conceito com solução. Decide antes quando ela morre, senão a POC vira produção por inércia, e aí você está sustentando processo crítico em gambiarra sem ter decidido isso.

A pergunta de um milhão: deu samba?

No fim de cada ciclo tem uma pergunta só: deu samba?

Não é "ficou bonito", não é "funcionou na demo", não é "entreguei no prazo". É: alguma coisa na vida de alguém ficou melhor, de um jeito que dá para perceber sem eu explicar?

Se você precisa de uma apresentação para provar que deu certo, talvez não tenha dado tanto samba assim.

Aí, a próxima decisão é: vale a pena melhorar ou melhor partir pra próxima?

Como medir sem virar burocracia

Quatro medidas cobrem quase tudo, e nenhuma exige ferramenta.

Tempo devolvido. Quanto tempo a tarefa levava e quanto leva agora, medido na mesma semana, pela mesma pessoa. É a medida mais honesta que existe porque ninguém consegue discutir.

Erro que sumiu. Quantas vezes por mês aquilo dava errado antes, e quantas dá agora. Vale mais que tempo em processo onde errar custa caro.

Decisão que ficou mais fácil. Essa é subjetiva e mesmo assim é a mais valiosa: aquilo que antes exigia reunião e agora se resolve olhando a tela.

Grana. Aumentou o faturamento ou diminuiu o custo? É a medida que fecha a conta das outras três.

Meça antes de mexer. Se você não anotou quanto tempo levava, você perdeu a única chance de saber se melhorou. Essa é a parte que eu mais vejo gente pular, e ela custa cinco minutos.

Cashback de tempo: por onde começar a recuperar seus preciosos minutos

A prática que eu uso e ensino é simples: investe de trinta minutos a uma hora montando alguma coisa, e essa coisa te devolve de trinta minutos a uma hora por dia.

Não é milagre e não acontece de uma vez. É acumulação. Você monta um por semana, e em alguns meses recuperou um dia inteiro da sua semana.

A conta é economia menos custo de montagem. Se levou três horas pra montar e devolve dez minutos por dia, você empata em dezoito dias, e isso é ótimo. Se levou três dias pra montar e devolve cinco minutos por dia, você escolheu o caminho errado.

E uma ressalva honesta: existe custo de manutenção, e ele não entra nessa conta. Uma gambiarra que depende do navegador aberto vai quebrar. Tudo bem começar assim, desde que você saiba que é gambiarra. O problema não é a gambiarra, é a gambiarra que você esqueceu que era gambiarra.

Seu primeiro sprint

Um exercício pra rodar agora, numa tarefa só. Dá pra fazer tudo num dia, se você tiver umas três horas livres: olhar e escolher cabem em meia hora. Ou dá pra espalhar pela semana, se você quiser explorar alternativas com calma antes de montar alguma coisa. O ritmo é seu. O que não dá é pular etapa.

1. Olhar. Lista três ou quatro candidatos: tarefas que se repetem e que você faz, ou alguém perto de você faz. Alguns que aparecem quase sempre: responder o mesmo tipo de mensagem várias vezes por dia, montar o relatório da semana, conferir planilha contra extrato, organizar documento que chega pelo WhatsApp, marcar e remarcar reunião. Pra cada um, anota quanto tempo leva e onde o processo engasga. Pensa em alguns jeitos de resolver o gargalo e anota as ideias.

2. Escolher e pesquisar. Pega o candidato que mais trava coisa depois dele. Antes de montar qualquer coisa, procura quem já resolveu: recurso nativo das ferramentas que você já usa, ferramenta pronta de mercado, repositório no GitHub, skill ou plugin em marketplace, template de automação. Pra cada achado, duas perguntas: como isso já resolve o problema? E quão perto está do que eu preciso? Às vezes a resposta está pronta e você só não tinha procurado.

3. Perguntar. Escreve a pergunta em par: o gargalo que você viu é real e do tamanho que você acha? E dá pra resolver com custo e tempo aceitáveis? Se não consegue escrever as duas, volta pro passo 1.

4. Montar o menor teste. Com o que você achou no passo 2, quase sempre algo pronto. Não é a solução, é o jeito mais barato de responder a pergunta. Se em uma hora não funcionou, a resposta é não, e isso é um resultado, não um fracasso.

5. Testar na mão de quem usa. Coloca na frente de quem faz a tarefa e fica do lado. Anota o que a pessoa tentou fazer que você não tinha previsto.

6. Deu samba? Quanto tempo leva agora, comparado com o que você anotou no passo 1? Se deu samba, passa a tarefa pela matriz de usar pronto, amarrar ou construir, pra decidir onde a solução de verdade vai morar. Se não deu, você descobriu alguma coisa que não sabia, e é por aí que o próximo ciclo começa.

Duas regras pra esse primeiro ciclo. Não tenta construir a solução definitiva ainda. Mesmo que pareça óbvio que o caso pede sistema próprio. O primeiro ciclo é pra responder uma pergunta, e a decisão de onde a solução mora vem depois, com evidência na mão. E não começa uma segunda tarefa antes de terminar essa. A tentação de abrir uma frente nova quando a primeira fica chata é a armadilha da barata-tonta aparecendo.

Um exemplo real

Pra mostrar como isso fica na prática, um caso meu.

No Colaboratório, boa parte da semana é reunião com cliente. Toda conversa termina com alguma decisão tomada e alguma coisa pra fazer, e alguém precisa transformar aquilo em tarefa no Linear, com responsável, antes que se perca. Esse alguém era eu.

Olhar. Eu já usava IA pra isso: jogava a transcrição com um prompt na minha LLM, conversava com ela até as tarefas ficarem claras e acionava os conectores na mão pra criar tudo. De 15 a 30 minutos por reunião. Funcionava, mas eu continuava sendo o gargalo: nada andava até eu parar pra fazer.

Escolher e pesquisar. O Granola e o Google Workspace já resolviam isso mais ou menos. Transcreviam, resumiam, listavam as conclusões. O problema é que as conclusões ficavam lá, esperando eu agir sobre elas. A ferramenta pronta chegava até o meio do caminho e parava exatamente no ponto que engasgava.

Perguntar. O gargalo era real, dava pra medir no relógio. E a pergunta mudou: consigo tirar as tarefas da transcrição e jogar no Linear sem eu no meio?

Montar o menor teste. Usei o conector do Claude pra monitorar novas transcrições de hora em hora e criar as tarefas no Linear, já com os responsáveis.

Testar na mão de quem usa. A decisão que fez isso funcionar foi aceitar que ele vai errar às vezes. Se uma tarefa não faz sentido, é só apagar. O contexto inteiro continua na transcrição.

Deu samba? Deu. A parte que engasgava sumiu. O que eu fazia na mão virou olhar o Linear e apagar o que não serve.

E na matriz fica claro por que isso é amarrar e não construir: acontece em toda reunião, as fontes já tinham conector, e o custo do erro é baixo, porque errar custa um clique e nada se perde. Se uma tarefa errada fosse parar na mão de um cliente, ou se apagar significasse perder informação, a conversa seria outra.

Vai dar alguma merda, e tá tudo bem

Em inovação, a máxima continua sendo "fail fast". Não que a gente persiga a falha, mas se ela é inevitável, vamos descobrir onde ela tá logo pra corrigir de uma vez e acertar mais rápido. Ou desistir e fazer algo que dê pra acertar.

Travou no passo 1, entender a operação. Quase sempre é porque você está olhando o processo que existe no papel em vez do que acontece na prática. Volte e sente ao lado de quem faz.

Travou no caminho. Se você confere tudo manualmente, a solução não aguenta o custo do erro daquele processo: volta pra matriz. Se ainda faz na mão todo dia há meses, já passou da hora de usar algo pronto ou amarrar.

Travou na medida. Não mediu antes, então não dá para saber se melhorou. Recomece medindo. Custa cinco minutos e é a diferença entre método e achismo.

Travou porque não é problema seu. Às vezes o que trava é organizacional, não técnico. Nenhuma automação resolve alguém que não quer mudar de processo.

E tem o caso em que você faz tudo certo e descobre que o trabalho é maior do que cabe no seu dia. Isso também é um resultado. Saber o tamanho real da coisa é exatamente o que separa quem decide de quem chuta.

Se você chegou até aqui, espero que tenha curtido e aprendido alguma coisa nova ou ligado os pontos de maneira diferente.

Publico esse método inteiro de propósito, e não é só generosidade. Se você tentar e conseguir, ótimo, eu queria mesmo que mais gente trabalhasse assim.

Se tentar e travar, você vai saber exatamente onde travou, e conversar comigo fica fácil. Se olhar o tamanho do trabalho e decidir que prefere não fazer sozinho, também fica.

Nos três casos, você sai sabendo mais do que entrou, que é a régua deste guia aplicada a ele mesmo.

Tenta e me conta se deu samba aí. É a parte que me interessa de verdade, porque cada trava que aparece vira o próximo capítulo disto aqui.

Alexandre

O guia numa página