Deep Content #16 - 5 Skills do Claude para decidir o que construir numa empresa AI first

Boa tarde. Bem-vindo novamente à InferêncIA News.

Uma ideia de empresa com IA pode ganhar nome, apresentação e protótipo antes de alguém responder quem realmente precisa dela. A facilidade de produzir mudou bastante. A necessidade de descobrir o que vale produzir continua dando trabalho.

É por isso que eu começaria a conversa sobre uma empresa AI first pelas decisões: como ela escolhe um problema, aprende com clientes e organiza a execução depois desse aprendizado. A IA pode participar de cada etapa. Mas produzir uma resposta convincente e reduzir uma incerteza são coisas diferentes.

Nesta edição, selecionei cinco Skills que ajudam a estruturar esse processo. Elas pertencem ao PM-Skills, da comunidade Product on Purpose, e foram escolhidas pelo método descrito nos arquivos originais. Não são Skills oficiais da Anthropic. São procedimentos publicados para trabalhar com agentes, incluindo Claude, e exigem avaliação no ambiente de quem vai usá-los.

O percurso passa por tese de negócio, hipótese, evidência, decisão de investimento e desenho de experimento. A empresa continua precisando de responsáveis por essas escolhas. A utilidade possível está em tornar as premissas e os critérios mais visíveis — inclusive os que fazem a equipe desistir de uma ideia pela qual já se apaixonou.

Uma Skill é um conjunto reutilizável de instruções e recursos. Aqui, cada uma orienta um tipo de análise e uma entrega específica. Um plugin pode distribuir várias Skills; um conector ou servidor MCP pode dar acesso a uma ferramenta. Nenhum desses conceitos significa, por si, uma empresa funcionando de forma autônoma.

O README do projeto descreve distribuição por plugin no Claude Code. Para o claude.ai, é necessário preparar o material como Skill personalizada conforme os requisitos do produto; não basta encontrar o arquivo na internet. Não instalamos nem executamos os pacotes. A leitura permite avaliar o procedimento proposto, não comprovar sua eficácia.

Para ligar as cinco etapas, vamos acompanhar um cenário inteiramente hipotético: uma equipe quer oferecer às pequenas distribuidoras um serviço de IA que prepare pedidos recebidos em mensagens. Não há entrevistas reais, demanda comprovada ou economia medida nesse exemplo. Justamente por isso, a primeira entrega não deveria ser um plano de expansão.

A foundation-lean-canvas orienta um quadro integrado da tese de negócio. Relaciona problema, clientes, proposta de valor, solução, canais, receitas, custos, métricas e vantagem competitiva. O arquivo exige distinguir informação validada, suposição e pergunta aberta, com confiança e responsável pela revisão.

No nosso cenário, o insumo seria uma descrição do serviço, o segmento pretendido, as alternativas usadas atualmente e os poucos sinais que a equipe já possui. O resultado esperado seria uma página mostrando como essas peças dependem umas das outras.

A análise pode revelar uma diferença importante entre usuário e comprador. O funcionário que recebe os pedidos talvez queira reduzir digitação; o dono da distribuidora pode estar mais preocupado com devoluções causadas por itens incorretos. Isso ainda seria uma hipótese a investigar, mas já mudaria a conversa sobre valor.

Eu pediria ao responsável pelo negócio que conferisse especialmente as células preenchidas com números. Uma estimativa de receita precisa mostrar suas premissas. Um canal acessível precisa ter alguma explicação além de “vamos divulgar nas redes”. E uma vantagem difícil de copiar pode continuar em branco quando ainda não existe.

A pergunta decisória é: temos uma tese coerente o suficiente para saber o que precisamos aprender? O quadro ajuda a tornar essa pergunta discutível. Não confirma tamanho de mercado, disposição de pagamento ou viabilidade técnica.

Esse seria o primeiro avanço: sair de “uma IA para distribuidoras” para uma descrição que permita discordância. Talvez a oportunidade esteja em conferir pedidos antes da digitação. Talvez o maior problema nem esteja nas mensagens. A equipe ainda não sabe, e o documento deve conservar essa informação.

A define-hypothesis transforma uma crença em afirmação testável: mudança proposta, público, resultado esperado e forma de avaliação. Suas instruções incluem métrica principal, limites para efeitos indesejados, riscos e condições de sucesso. Ela prepara o que testar; o desenho detalhado vem depois.

No cenário hipotético, “automatizar pedidos vai melhorar a operação” é amplo demais. Uma formulação mais útil seria investigar se um rascunho preparado por IA reduz o trabalho total de registrar pedidos de um segmento específico, preservando a qualidade dos registros.

O trabalho total precisa incluir a revisão. Se alguém digita menos e passa mais tempo corrigindo códigos de produto, a contagem de teclas pode melhorar enquanto a rotina piora. Essa escolha de métrica já é uma decisão empresarial.

Para começar, a equipe forneceria o fluxo atual, o tipo de pedido, quem o processa e o resultado que pretende observar. A saída revisável seria uma ficha com a hipótese, os dados necessários e o que contaria contra ela.

Há um cuidado no próprio uso da Skill: o arquivo pede metas numéricas, mas o modelo não conhece automaticamente a referência da operação. Se não houver medição inicial, essa ausência deve ficar explícita. O responsável pode definir um limiar provisório, com justificativa, ou planejar primeiro a coleta da referência. Inventar precisão só deixaria a ficha mais apresentável.

Quem responde pela operação aprova a hipótese e os limites de qualidade. A pergunta é: qual observação nos faria mudar de opinião? Se toda resposta possível puder ser interpretada como incentivo para continuar, temos uma intenção, ainda não um teste.

A discover-interview-synthesis trabalha sobre entrevistas já realizadas. Pede contexto dos participantes, temas recorrentes, citações atribuídas a IDs, interpretações, recomendações e limitações. Sua função é sintetizar pesquisa fornecida, não produzir entrevistas que não aconteceram.

Essa é a etapa em que a tese precisa encontrar a rotina das pessoas. No nosso exemplo, uma pesquisa futura poderia ouvir quem recebe mensagens, quem confere estoque e quem resolve divergências de pedidos. A entrada seria um conjunto autorizado e anonimizado de registros, acompanhado das perguntas da pesquisa e das condições de recrutamento.

Uma saída útil mostraria quais relatos sustentam cada conclusão. Imagine que algumas pessoas mencionem demora na digitação, enquanto outras apontem descrições ambíguas dos produtos. Esses sinais poderiam indicar problemas diferentes. Resumi-los como “clientes querem automação” apagaria justamente o que a equipe precisa entender.

A revisão exige voltar às falas. Uma citação foi preservada? A interpretação tem apoio? Quem discordou continua visível? O responsável pela pesquisa deve distinguir recorrência naquele grupo de frequência no mercado.

O arquivo traz orientações numéricas sobre participantes e recorrência. Elas não são uma garantia de representatividade nem uma regra estatística universal. Recrutar apenas conhecidos disponíveis, por exemplo, limita as conclusões mesmo quando o documento contém várias citações.

A pergunta decisória é: qual parte da nossa hipótese ganhou apoio, qual foi contrariada e qual continua sem evidência? Uma síntese pode recomendar novas conversas. Isso pode ser um resultado muito melhor do que confirmar com entusiasmo uma solução que ninguém chegou a discutir.

Também vale lembrar: a IA pode organizar bem um material ruim. A qualidade da entrevista e a seleção das pessoas continuam sendo trabalho da pesquisa.

A foundation-build-risk-review propõe uma revisão antes de comprometer esforço de construção. A entrega inclui um risco principal, evidências, uma recomendação e um próximo passo de validação. A taxonomia de apoio diferencia riscos como demanda, distribuição, monetização, confiança e retenção.

Depois das entrevistas, a equipe hipotética poderia fornecer a tese atualizada, os relatos e as restrições conhecidas. Talvez o ponto mais frágil seja a confiança: as pessoas podem desejar ajuda, mas não aceitar que mensagens comerciais circulem por um serviço externo.

Nesse caso, demonstrar que o modelo consegue extrair produtos de uma mensagem não resolve a questão decisiva. O próximo passo poderia ser investigar quais dados poderiam ser usados, em quais condições e com qual autorização. Esse é um exemplo editorial de encaminhamento, não uma conclusão sobre distribuidoras reais.

O valor dessa Skill está em exigir uma razão principal para a recomendação. A equipe consegue discutir se o risco escolhido merece vir antes dos demais. Também pode contestar a leitura feita pela IA.

Eu acrescentaria uma verificação humana: o risco principal está apoiado no material ou foi escolhido porque é fácil de explicar? E existe alguma restrição que impeça o avanço independentemente da prioridade atribuída, como impossibilidade de usar os dados necessários? Um risco dominante não torna os outros irrelevantes.

A decisão final pertence a quem assume o investimento e suas consequências. “Validar primeiro” precisa se transformar numa ação com responsável e pergunta definida. “Construir algo pequeno” precisa ter escopo suficiente para aprender, sem ganhar automaticamente autorização para integrar sistemas de clientes.

A revisão é útil justamente quando permite adiar a implementação por uma razão verificável. Código pronto pode custar menos do que antes; construir a coisa errada ainda ocupa atenção, suporte e confiança.

A measure-experiment-design orienta o planejamento de um experimento para uma hipótese existente. Pede comparação, métricas, dimensionamento, duração, público, critérios de sucesso e medidas de proteção. Inclui resultado inconclusivo entre as possibilidades e separa planejamento de análise de resultados.

No cenário hipotético, a equipe poderia começar com pedidos fictícios ou materiais cujo uso tenha sido autorizado. O fluxo proposto prepararia rascunhos, sem enviar mensagens, confirmar vendas ou alterar estoque. Uma pessoa verificaria tudo antes de qualquer uso operacional.

O insumo seria a hipótese anterior, a referência disponível, o volume de casos e as restrições. A saída seria um protocolo revisável: o que comparar, como registrar tempo e erros, quem confere e em quais condições interromper.

Há uma diferença entre um piloto de viabilidade e um teste que permite estimar efeito. Trabalhar com poucos exemplos pode revelar falhas relevantes, mas não demonstra economia generalizável. Se o objetivo for uma comparação quantitativa, dimensionamento e desenho precisam de revisão adequada; não devem ser aceitos só porque Claude apresentou uma fórmula.

Também seria preciso definir a unidade observada. Vários pedidos do mesmo atendente não são automaticamente observações independentes. Pedidos muito simples de um lado e complexos do outro podem distorcer a comparação. Essas são perguntas de desenho que a equipe deve levar a quem sabe avaliar o método.

A pergunta decisória é: quais resultados autorizam continuar, ajustar ou interromper? Os critérios precisam existir antes de conhecer o resultado. Se a economia só aparece ao excluir a revisão ou ao retirar os casos difíceis depois do teste, a empresa aprendeu algo diferente do que imaginava.

O responsável pelo experimento registra a conclusão e o alcance dela. A Skill prepara o plano; não coleta dados por conta própria nem transforma ausência de evidência em sinal verde.

As cinco Skills foram escolhidas do mesmo projeto porque oferecem entregas distintas que podem conversar entre si. Não é necessário usá-las como uma sequência obrigatória. Quem já tem pesquisa pode começar pela síntese; quem percebe um impedimento relevante pode antecipar a revisão de risco.

O encadeamento possível é explicitar o problema na tese de negócio, formular uma hipótese, confrontá-la com evidências e decidir qual incerteza merece um experimento. Depois, os resultados voltam à tese. Uma mudança de segmento, de proposta ou de processo pode ser o aprendizado mais importante.

O guia de plataformas do projeto documenta distribuição para Claude Code e caminhos para outros ambientes. Estas cinco são Skills de comunidade sob Apache-2.0, conforme os arquivos consultados. Isso não é aval da Anthropic nem garantia de qualidade. Não verificamos funcionamento em Cowork ou em uma conta individual. Custos do modelo, permissões e recursos disponíveis dependem do ambiente; não foram comparados aqui.

Para um primeiro experimento de baixo impacto, eu escolheria uma decisão interna já pendente: investir ou não numa pequena automação. Forneceria uma descrição sem dados confidenciais e as evidências existentes para uma revisão de risco. A pessoa responsável conferiria cada evidência e avaliaria se a recomendação fez surgir uma pergunta útil.

Essa primeira avaliação é sobre a qualidade do apoio à decisão, não sobre o sucesso da empresa. Se o relatório apenas reorganizar opiniões antigas, esse limite deve ser registrado. Se ajudar a perceber uma premissa importante, a próxima ação será buscar evidência para ela.

Minha leitura de empresa AI first é essa: IA participando de como a organização decide, aprende e organiza a execução. O ganho possível não está em ter uma resposta para tudo. Está em conseguir explicar melhor o que se sabe, o que se está supondo e por que a próxima ação merece acontecer.

Qual decisão da sua empresa hoje depende mais de uma suposição do que de evidência? Responda com a pergunta, sem compartilhar informações confidenciais. Ela pode ser um ponto de partida mais útil do que outra lista de ferramentas.
Nos vemos amanhã.

Filipe, o único humano nesta empresa.