Fundador de IA que está a construir um negócio autónomo explica como criar fluxos de trabalho baseados em agentes para a entrega de projetos e o apoio ao cliente

Esta limitação transformou-se num laboratório acidental para a entrega de projetos. Quando não se pode resolver os problemas simplesmente contratando mais pessoas, cada decisão relativa a um projeto torna-se existencial: isto vai multiplicar por 10 a nossa produção ou é apenas atividade que parece progresso?

Esse filtro implacável revelou padrões que não conseguia ver quando tinha o luxo de lançar pessoas para os problemas nas minhas duas startups anteriores, que fundei e fiz crescer com base na antiga estratégia de crescimento a qualquer custo. Agora, depois de ver mais de 200 empresas implementarem IA através do produto da Swan, consigo identificar instantaneamente os padrões de falha.

You should also read

• Gestor de Projetos e Educador com IA Partilha um Fluxo de Trabalho Simples com IA que Altera Fundamentalmente a Forma como os Projetos Funcionam

• Os fluxos de trabalho de IA do mundo real utilizados pelo Diretor de Entregas de uma agência de implementação do Asana

Porque é que a IA está a transferir a entrega de projetos do planeamento para o reconhecimento de padrões e a velocidade de decisão

A mudança mais dramática é a forma como distribuo o meu tempo — e é quase o inverso da gestão de projetos tradicional. Dedico muito pouco tempo às tarefas que costumavam exigir a minha atenção, como o planeamento inicial, as reuniões de acompanhamento e a documentação que ninguém lê. Falarei mais sobre isso dentro de instantes.

Eis o que está a captar a minha atenção agora:

• 60% é dedicado ao reconhecimento de padrões e à tomada de decisões: Analiso em tempo real o que está a funcionar nas nossas mais de 200 implementações. Não são análises mensais — é a identificação diária de padrões. Que implementações estão a gerar resultados cumulativos e quais estão a estagnar? Onde estão realmente a surgir os estrangulamentos, em comparação com os locais onde prevíamos que surgissem? O objetivo é tomar decisões rápidas sobre o que eliminar e em que apostar ainda mais, e não é possível fazer isso numa reunião trimestral de análise do negócio. Para isso, temos um painel no Retool para acompanhar a saúde dos clientes e apresentar alertas no Slack. Também utilizo o Metabase, onde temos análises de produto mais detalhadas por cliente.
• 30% é dedicado à criação de ciclos de feedback: Como sabemos, no prazo de 48 horas, se uma implementação de IA está a funcionar? Que sinais nos indicam que devemos mudar de rumo ou persistir? Estou a criar “sistemas de deteção de falhas” — formas de detetar quando a IA se desvia do guião ou quando um fluxo de trabalho não está a produzir resultados, antes de isso se tornar uma crise. Para isso, é importante definir um plano claro que comece por pequenos passos fáceis de medir. Os gestores de projeto tradicionais planeavam para o sucesso; eu estou a conceber sistemas que tornam as falhas imediatamente visíveis, para que possamos corrigi-las enquanto ainda são pequenas.
• 10% é dedicado ao verdadeiro “lançamento do projeto”: Isto costumava ser o clímax de meses de planeamento. Agora é apenas terça-feira. Estamos constantemente a lançar versões 1 e encaramos o lançamento como o início da aprendizagem, não como o fim do planeamento. O lançamento já não é sinónimo de sucesso — é a autorização para começar a recolher feedback real.

Num mundo orientado para a IA, a execução é barata e rápida. O estrangulamento está na velocidade de decisão. O meu papel passou de “elaborar o plano perfeito” para “tomar decisões rápidas com base em feedback real”. É por isso que dedico 90% do meu tempo a sistemas de aprendizagem, não a sistemas de execução.

Num mundo orientado para a IA, a execução é barata e rápida. O estrangulamento está na velocidade de decisão.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Amos Bar Joseph

CEO da Swan AI

Como eliminar o custo da coordenação na entrega de projetos

A nossa transição da gestão de projetos tradicional para uma gestão de projetos mais simples não foi uma mudança de metodologia; consistiu em eliminar rituais específicos que nos atrasavam. Eis o que desapareceu e o que o substituiu:

Reuniões de acompanhamento (40% do calendário) → Atualizações assíncronas (agora 5% do tempo)

• Eliminado: Reuniões semanais de acompanhamento dos projetos com apresentações
• Substituído por: Breves atualizações no Slack quando algo muda, não segundo um calendário
• Porque funciona: A informação circula quando é importante, não quando o calendário o determina
• Resultado: Recuperámos mais de 15 horas por semana por fundador

Planos de projeto detalhados (2–4 semanas iniciais) → Definições de resultados (2–4 horas)

• Eliminado: Documentação abrangente de requisitos, mapas de processos, matrizes de risco
• Substituído por: O resultado claro que queremos e a primeira experiência a realizar
• Porque funciona: Os planos tornam-se imediatamente obsoletos; os resultados continuam a ser relevantes
• Resultado: Lançamento das primeiras versões em dias, não em meses

Cadeias de aprovação → Direitos de decisão claros

• Eliminado: "Submeter isto à liderança" para pequenas decisões
• Substituído por: Limiares definidos — abaixo de $X ou de um impacto Y, basta avançar
• Porque funciona: A rapidez é mais importante do que evitar pequenos erros
• Resultado: O tempo entre a decisão e a ação diminuiu de dias para horas

Revisões trimestrais → Indicadores de retorno diários

• Eliminado: Reuniões agendadas para "ver como está a correr este projeto"
• Substituído por: Métricas automatizadas que nos alertam quando algo está errado
• Porque funciona: Detetar problemas no dia 2, não no mês 3
• Resultado: Problemas resolvidos antes de se transformarem em crises

Passámos de dedicar 60% do tempo à coordenação do trabalho para dedicar 90% do tempo à realização do trabalho. Não porque sejamos mais disciplinados, mas porque eliminámos o imposto de coordenação que a gestão de projetos tradicional cria.

Como a IA muda os rituais de entrega ao exigir um contexto mais rico

O pensamento tradicional parte do princípio de que a IA significa menos comunicação humana. A nossa realidade é o oposto: ter IA na equipa significa comunicarmos de forma mais explícita, porque a IA precisa de contexto para ser útil.

Isto é particularmente relevante para nós porque estamos a utilizar o nosso próprio produto para eliminar o "imposto de contexto" — o que significa que este se integra nos nossos canais de comunicação para recolher e obter contexto. Está atento.

Isto tem um grande impacto nos nossos rituais. Os projetos de sucesso do cliente são um bom exemplo. Quando um cliente comunica um problema ou solicita algo, os nossos fundadores comunicam intencionalmente com mais profundidade do que seria necessário entre nós — porque sabemos que a IA está a captar essa informação.

Na prática, é assim que funciona:

Em vez de: "O cliente X quer a funcionalidade Y, vamos discutir amanhã"

Escrevemos: "O cliente X solicitou a funcionalidade Y. Contexto: está a enfrentar problemas de escala com 200 potenciais clientes/dia, a sua equipa de 3 SDRs está sobrecarregada e esta funcionalidade permitiria gerir 500/dia sem contratar. Isto está alinhado com o nosso ICP de expansão para PME. Urgência: elevada — esta semana estão a avaliar concorrentes."

Mais tarde, quando qualquer pessoa da equipa — incluindo a IA — interage com esse cliente, temos acesso ao contexto relevante.

Sim, isto exige mais 2 a 3 minutos por comunicação. Mas poupa horas em:

• Reuniões de alinhamento — a IA mantém todos sincronizados
• Recolha de contexto — a IA já conhece a situação
• Transições — a IA mantém o contexto entre interações

Quando trata a IA como um membro da equipa que precisa de se manter a par, os seus rituais de comunicação e documentação mudam fundamentalmente — e é nesse momento que a IA se torna verdadeiramente útil, não apenas uma funcionalidade.

Sugestão do Amos

Quando trata a IA como um membro da equipa que precisa de se manter a par, os seus rituais de comunicação e documentação mudam fundamentalmente — e é nesse momento que a IA se torna verdadeiramente útil, não apenas uma funcionalidade.

Porque é essencial definir primeiro os papéis humanos para uma implementação bem-sucedida da IA

As falhas na implementação da IA quase nunca acontecem porque a IA não é suficientemente capaz. Falham porque as equipas nunca responderam a uma questão mais fundamental: "O que devem realmente assumir os seres humanos neste processo?"

Eis o padrão que vejo constantemente nas mais de 200 implementações que realizámos:

As equipas passam semanas a perguntar "A IA consegue tratar desta tarefa?" Mapeiam o processo atual, identificam o que a IA pode automatizar, criam o sistema e lançam-no. A IA funciona. Consegue realizar 70-80% da tarefa de forma fiável.

Depois, tudo se desmorona. Não porque a IA falhe, mas porque ninguém definiu o que os seres humanos devem fazer com os 20-30% restantes. Por isso, acontece uma de duas coisas:

1. Os seres humanos controlam tudo ao pormenor. Não confiam na IA, por isso reveem cada decisão, transformando efetivamente uma implementação de IA de $20K numa dispendiosa ferramenta de sugestões. A equipa esgota-se a verificar os trabalhos de casa da IA.
2. Os seres humanos abandonam completamente a responsabilidade. Partem do princípio de que "a IA está a tratar disso" e deixam de prestar atenção. Depois, algo avaria-se ou sai do guião, e ninguém se apercebe até se transformar numa crise para o cliente.

Isto acontece porque abordámos a implementação da IA ao contrário. Perguntámos «O que podemos automatizar?» em vez de «Onde é que o julgamento humano é insubstituível e como podemos criar IA que amplifique esse julgamento?»

Em vez disso, comece todos os projetos de IA por definir primeiro o papel humano. Que decisões exigem intuição? Onde é que o contexto é fundamental? Que modos de falha requerem supervisão humana? Depois, crie IA para tratar de tudo o resto e apresentar os sinais certos no momento certo para a tomada de decisões humanas.

À posteriori, parece óbvio. Mas quando estamos entusiasmados com as capacidades da IA, é incrivelmente fácil saltar este passo e concentrarmo-nos inteiramente naquilo que a IA pode fazer — em vez de concebermos antecipadamente a colaboração entre humanos e IA.

Um quadro prático para decidir o que a IA deve automatizar

Penso nas decisões de automatização segundo duas dimensões: impacto do erro e complexidade do julgamento necessário. Isto cria quatro categorias claras, que abordarei dentro de momentos.

À medida que aumenta a complexidade ou o impacto, o papel da IA passa de «responsável» a «assistente». Mas é necessário definir antecipadamente qual o papel que a IA desempenha em cada fluxo de trabalho — não depois do lançamento, quando os humanos não sabem se devem confiar nas decisões da IA ou contrariá-las.

O quadro não diz respeito ao que a IA pode fazer tecnicamente. Diz respeito ao que a IA deve assumir, tendo em conta o perfil de risco e o julgamento necessário.

Baixo impacto + baixa complexidade = automatização total

Exemplo 1: Enriquecimento de dados e pesquisa

• A IA recolhe informações sobre empresas, conjuntos tecnológicos e perfis nas redes sociais
• Se algo estiver errado, os humanos detetam-no durante a revisão
• Não é necessário qualquer julgamento — apenas recolha de dados
• Implementação: integrações de API, a IA estrutura os resultados e é feita uma verificação humana pontual

Exemplo 2: Qualificação e encaminhamento iniciais de oportunidades

• A IA atribui uma pontuação com base em critérios ICP definidos e encaminha para o fluxo de trabalho adequado
• Os encaminhamentos incorretos são óbvios e facilmente corrigidos
• A lógica pode ser codificada (dimensão da empresa, setor, sinais comportamentais)
• Implementação: pontuação baseada em regras + IA, com revisão humana dos casos excecionais

Baixo impacto + elevada complexidade = preparação pela IA, decisão humana

Exemplo: Respostas do apoio ao cliente

• A IA redige respostas com base em casos semelhantes do passado
• É complexo porque o tom, o contexto e os casos excecionais são importantes
• Mas o impacto é baixo se fizermos uma revisão antes do envio
• Implementação: a IA redige, um humano revê/edita e aprendemos com as edições

Elevado impacto + baixa complexidade = automatização com salvaguardas

Exemplo: Envio de mensagens de prospeção

• O impacto é elevado porque pode prejudicar a sua marca/mercado se for feito incorretamente
• Mas é relativamente pouco complexo — e a qualidade pode ser medida
• Implementação: a IA gera o conteúdo, existem fluxos de aprovação rigorosos e mecanismos automáticos de interrupção quando o desempenho diminui

Elevado impacto + elevada complexidade = responsabilidade humana

Exemplo: Mudanças estratégicas de projetos

• Decidir se se deve abandonar ou reforçar uma implementação
• Exige reconhecimento de padrões em vários contextos
• Uma decisão errada é dispendiosa devido aos recursos desperdiçados ou à oportunidade perdida
• Implementação: a IA apresenta sinais (diminuição da utilização, padrões nas opiniões) e um humano toma a decisão

Exemplo: Negociações complexas com clientes

• Discussões sobre preços, conversas sobre expansão e riscos de renovação
• Exige interpretar a dinâmica da relação, o contexto político e as preocupações não expressas
• Cometer um erro prejudica uma relação de confiança que é difícil reconstruir
• Implementação: a IA faz a pesquisa e a preparação, enquanto um humano assume a conversa

Como os fluxos de trabalho autónomos permitiram criar um sistema de apoio autodidata em 13 horas

Eis um exemplo da complexidade que conseguimos gerir utilizando fluxos de trabalho autónomos na procura de criar uma empresa automatizada.

A restrição: Trabalhar para atingir $10M de ARR por funcionário com apenas 3 fundadores significava que não podíamos contratar para resolver os problemas. Quando os pedidos de suporte chegaram a mais de 200 por semana, a resposta tradicional — contratar 2 CSMs — não estava ao nosso alcance. Cada pedido exigia toda a atenção de um fundador — pesquisar a resposta, redigir a resposta e documentá-la em algum lugar. Estávamos a afogar-nos.

V1 (semana 1): Responder a perguntas conhecidas

Começámos com o mínimo absoluto: um agente de IA no Slack que conseguia responder a ~20 perguntas que já tínhamos documentado no Notion.

• Ferramentas: Swan AI, Slack, Notion
• Configuração: 6 horas
• Resultado: 15% dos pedidos tratados
• Novo problema: Os clientes estavam frustrados por receber respostas do tipo "Não sei". Continuávamos a responder manualmente a 85% dos pedidos.

V2 (semana 2): Encaminhar perguntas desconhecidas

Adicionámos um processo de escalamento: a IA permanece no tópico do cliente, mas envia-nos uma notificação interna quando não sabe alguma coisa. Respondemos e a IA transmite a nossa resposta.

• Configuração: 3 horas
• Resultado: 35% de resolução autónoma
• Novo problema: Percebemos que estávamos a responder repetidamente às mesmas perguntas novas. Cada escalamento não ensinava nada à IA — era apenas um sistema de encaminhamento.

V3 (semana 4): Aprender com os escalamentos

Criámos o ciclo de aprendizagem. Agora, quando respondemos a uma pergunta escalada, a IA regista automaticamente as perguntas e respostas, estrutura-as e adiciona-as à base de conhecimento.

• Configuração: 4 horas
• Resultado: 70% de resolução autónoma no prazo de 2 semanas

Porque funcionou: Cada versão demorou menos de 6 horas a criar porque não estávamos a planear a perfeição — estávamos a responder a feedback específico. A capacidade de "autoaprendizagem" não fazia parte do plano original. Surgiu naturalmente quando perguntámos: "Porque estamos a responder duas vezes às mesmas perguntas?"

Agora, estamos a responder a mais de 200 pedidos por semana, 70% dos quais são tratados de forma autónoma, e a nossa base de conhecimento está a crescer organicamente a partir de perguntas reais dos clientes.

Por isso, aqui fica o meu conselho: Lance o mínimo que resolva o problema imediato. Observe onde falha. Adicione a funcionalidade mínima para corrigir essa falha. Repita. Chegámos a um sistema sofisticado de autoaprendizagem sem nunca o termos planeado de início.

Outros contextos propícios a fluxos de trabalho autónomos

Também estamos a utilizar fluxos de trabalho autónomos em:

• Integração: Novo cliente → a Swan orienta a configuração de forma conversacional, faz perguntas sobre o ICP e configura fluxos de trabalho com base nas respostas
• Sucesso: Monitoriza padrões de utilização → assinala oportunidades de expansão ou riscos → apresenta-os aos fundadores com recomendações

Porque os ciclos de retorno são mais importantes do que a escolha da ferramenta de IA e como criá-los

Toda a gente pergunta: "Que ferramenta de IA devemos utilizar?" É a pergunta errada.

O que mais nos poupa tempo não é uma ferramenta — é sabermos no prazo de 48 horas quando alguma coisa falha.

Integramos ciclos de retorno em todas as implementações. Acompanhamos:

• Padrões de escalamento: Quando a IA encaminha para pessoas, isso indica que precisa de ajuda
• Taxas de substituição manual: Quando as pessoas alteram os resultados da IA, isso indica que o discernimento foi fraco.
• Métricas de resultados: Reuniões marcadas, pedidos resolvidos, etc. — não apenas atividade.
• Acionadores de falhas: Alertas automáticos quando o desempenho diminui.

Sem ciclos de retorno, lançamos a IA e esperamos que esteja a funcionar. Quando percebemos que não está — normalmente através de reclamações ou revisões trimestrais — já desperdiçámos meses.

Com ciclos de retorno, detetamos os problemas em dias e corrigimo-los enquanto ainda são pequenos.

Já observámos um impacto real:

• IA de suporte: de 35% para 70% de autonomia em 2 semanas, ao perceber quais as perguntas que precisavam de respostas melhores
• IA de qualificação: melhoria de 40% na precisão em 30 dias, através do acompanhamento das substituições manuais

A escolha da ferramenta de IA é muito menos importante do que a sua capacidade de detetar o que está avariado e iterar rapidamente. A "ferramenta" que mais tempo poupa é o sistema que lhe diz o que precisa de ser corrigido antes de se tornar uma crise.

Um conjunto tecnológico nativo de IA que permite a execução autónoma de projetos

Dito isto, tenho algumas ferramentas essenciais:

• Projetos Claude (ferramenta de produtividade com IA): crio e aperfeiçoo todos os documentos relacionados com o projeto num Projeto Claude. Desta forma, o contexto da IA acumula-se e torna-se mais inteligente a cada conversa.
• Shortwave (ferramentas de comunicação com IA): é um novo cliente de e-mail nativo de IA, com um agente de IA integrado que me ajuda a recuperar facilmente o contexto certo de toda a desorganização da minha caixa de entrada. Também me ajuda a escrever excelentes e-mails e a manter as partes interessadas sincronizadas, sem alternar entre contextos nem ficar submerso na pesquisa de conversas anteriores.
• N8N (software de automatização de fluxos de trabalho com IA): utilizo-o para criar agentes de IA ligados ao nosso Retool e Metabase, para podermos receber atualizações dos projetos diretamente no Slack.

Porque é que a gestão de projetos está a evoluir para a gestão da velocidade

A IA na gestão de projetos irá evoluir da entrega de projetos discretos para a gestão da velocidade com adaptação contínua.

Acredito que a IA tornará a criação e a alteração de coisas tão rápidas que os projetos com inícios e fins definidos se tornarão obsoletos. Quando um projeto de 3 meses terminar, os requisitos terão mudado, as capacidades da IA terão evoluído e a solução "completa" já estará desatualizada.

O que a substituirá serão ciclos de melhoria contínua com ciclos de feedback rápidos. Em vez de "lançar o portal do cliente no T3", passará a ser "evoluir continuamente as interações com os clientes e implementar alterações diariamente com base em feedback real".

Os "gestores de velocidade" irão otimizar:

• Velocidade do feedback à correção — não datas de entrega
• Frequência das iterações — não conclusão do projeto
• Velocidade de aprendizagem — não gestão do âmbito

O sucesso será definido pela rapidez com que deteta problemas e implementa soluções, não pelo cumprimento de marcos predefinidos.

Os gestores de projetos que sobreviverem já estão a desenvolver esta capacidade — a lançar versões 1 imperfeitas, a iterar com base na utilização real e a otimizar a velocidade em detrimento da perfeição. Aqueles que ainda aperfeiçoam os seus diagramas de Gantt não reconhecerão a profissão daqui a cinco anos.

Porque é que a velocidade de iteração supera o planeamento — e como os líderes podem implementar mais rapidamente com IA

Eis o meu conselho: desenvolva para obter velocidade de iteração, não para alcançar a perfeição da implementação.

Pare com: planeamento de várias semanas, lançamentos perfeitos e evitar todas as falhas.

Comece a: lançar versões mínimas úteis em poucos dias, criar primeiro ciclos de feedback e aprender com iterações rápidas.

E torne-o prático: reduza em 75% a fase de planeamento do seu próximo projeto. Lance esta semana algo imperfeito que lhe ensine o que realmente importa. Meça o sucesso pela rapidez com que passa de "isso avariou" para "aqui está a v2".

A velocidade de aprendizagem supera sempre a profundidade do planeamento.

A velocidade de aprendizagem supera sempre a profundidade do planeamento.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Amos Bar Joseph

CEO da Swan AI

Acompanhe

Pode acompanhar o trabalho do Amos na automatização de fluxos de trabalho de GTM no LinkedIn e no boletim informativo da Swan. Também pode conhecer a Swan e o Autonamos, o clone digital do Amos.

Em breve, haverá mais entrevistas com especialistas no The Digital Project Manager!