O Motor de Projetos

In partnership with

The Future of Shopping? AI + Actual Humans.

AI has changed how consumers shop by speeding up research. But one thing hasn’t changed: shoppers still trust people more than AI.

Levanta’s new Affiliate 3.0 Consumer Report reveals a major shift in how shoppers blend AI tools with human influence. Consumers use AI to explore options, but when it comes time to buy, they still turn to creators, communities, and real experiences to validate their decisions.

The data shows:

• Only 10% of shoppers buy through AI-recommended links

• 87% discover products through creators, blogs, or communities they trust

• Human sources like reviews and creators rank higher in trust than AI recommendations

The most effective brands are combining AI discovery with authentic human influence to drive measurable conversions.

Affiliate marketing isn’t being replaced by AI, it’s being amplified by it.

Download the full report to see what this means for your brand.

Acima temos o anunciante da News dessa semana 🚀 Se puder, clique no link do anunciante acima para deixar seu apoio (é grátis!) ❤️

Você já viu um projeto morrer entre a ideia e a entrega?

O mockup perfeito que perdeu a alma na implementação.

A feature "tecnicamente impossível" descoberta depois de três semanas de design.

O roadmap que parecia brilhante na planilha — até o código encontrar a realidade.

A verdade incômoda é esta: a maioria dos projetos não falha por falta de talento. Falha por falta de sistema. Falha porque ninguém definiu direito o que construir, como entregar, e o que aprender depois.

E aí entramos num ciclo vicioso: estimativas furadas, escopo que cresce como bola de neve, e aquela reunião de retrospectiva onde todo mundo concorda que "da próxima vez vai ser diferente" — só que nunca é.

Drew Barontini, product builder que já passou por esse ciclo inúmeras vezes, propõe uma abordagem diferente. Ele chama de Project Engine — um motor de projetos que transforma apostas em resultados através de três fases integradas: Seleção, Entrega e Revisão.

🎲 Projetos São Moeda

Antes de mergulhar no sistema, um enquadramento importante.

Projetos são a moeda do trabalho de produto.

Pense nisso: cada projeto é uma unidade de trabalho com início e fim definidos.

É uma aposta. Você investe tempo, energia e recursos esperando um retorno — mais receita, mais clientes, menos churn.

Drew coloca assim: sinais emergem e apontam para um problema que, com alguma certeza, vai gerar resultados. Sua intuição ajuda. Timing ajuda. Sorte também. Mas não importa o que você faça, ainda está adivinhando até entregar algo e receber feedback — principalmente de pessoas pagando.

Se projetos são tão importantes, então você deveria ficar muito bom em três coisas:

1. Selecionar os projetos certos

2. Entregar com velocidade e qualidade

3. Revisar para aprender e melhorar

Esse é o Motor de Projetos.

🎯 Pilar 1: Seleção de Projetos

A seleção de projetos começa com discussão. Debate saudável sobre o que trabalhar, quem vai trabalhar, e quanto tempo dedicar. Não existe bala de prata ou matriz mágica de priorização.

Esse é o trabalho.

Para colocar as apostas certas, você precisa monitorar todos os inputs: canais do time, emails, issues, dados de uso, chamadas com clientes, tickets de suporte, objetivos de negócio. Tudo adiciona fidelidade ao seu conhecimento.

Drew sugere alinhar três elementos essenciais:

A Intenção

A intenção é composta por:

Problem Frame: A fatia mais estreita do problema que você pretende resolver. Não "usuários têm dificuldade para fazer login."

Mas sim: "Usuários não lembram qual método de autenticação usaram, forçando-os a resetar senha infinitamente, abrir tickets de suporte e consumir tempo de engenharia investigando."

Expected Value: O valor esperado em troca do problema resolvido. Se o Problem Frame está bem escrito, o valor emerge naturalmente: proteger receita, evitar custos, reduzir churn.

Clear Urgency: Por que resolver agora? Por que é mais urgente que outros problemas? O que acontece se você não resolver?

O Time

Drew identifica três tipos de equipe:

Integrated Team: Uma equipe completa com estrategista, designer e engenheiro trabalhando juntos do início ao fim. Usado para os problemas mais difíceis com mais incógnitas.

Engineering Team: Um ou dois engenheiros em trabalho majoritariamente técnico ou de back-end. Ideal quando o output de valor já está claro.

Copilot Team: Um estrategista e um designer trabalhando com agentes de código AI. Uma nova categoria para a era de LLMs e ferramentas de codificação agenticas.

O interessante é a flexibilidade: um projeto pode começar como Engineering, depois adicionar um designer para refinamento.

Ou começar como Copilot e trazer engenharia depois. O que importa é pensar sobre qual time você precisa para o problema em questão.

As Restrições

Aqui está uma mudança de paradigma:

Em vez de mentir para si mesmo com estimativas, defina quanto tempo você está disposto a gastar na solução.

Drew chama isso de Time Budget — um orçamento de tempo. Shape Up chama de apetite. A ideia é a mesma: se você fixa o tempo, precisa variar o escopo.

Além do orçamento de tempo:

• Project Timeline: Datas de início e fim

• Scope Boundaries: Áreas específicas para evitar no trabalho

O output da Seleção de Projetos é uma aposta. Você decidiu o problema, o time e as restrições. Agora é hora de construir.

🔨 Pilar 2: Entrega de Projetos

A Entrega de Projetos é quando o trabalho real começa. Você sai da discussão e entra na criação.

O diferencial aqui é a integração. Uma equipe integrada trabalha o problema de ponta a ponta. Eles clarificam o problema, modelam a solução e constroem iterativamente como um time único e unificado — sem hand-offs, sem cascata, sem contexto perdido.

As 3 Fases Integradas

Clarify: O time garante clareza completa sobre o problema.

Model: Modelam a solução com artefatos de baixa fidelidade para acelerar iteração. Mas o engenheiro também deve estar no código cedo. O objetivo é sempre chegar ao contexto final o mais rápido possível. Escrever código, prototipar, sentir o produto ao vivo.

Build: Constroem contra o que foi modelado para entregar os escopos individuais de trabalho. Criam fatias verticais de valor real — front-end e back-end fundidos em uma unidade. Progresso, momentum e tensões surgem cedo.

Breakpoints: Decisões em Tempo Real

Durante a entrega, surgem pontos onde você precisa fazer mudanças importantes para manter o cronograma. Drew chama de Project Breakpoints — assim como breakpoints em Responsive Web Design adaptam o layout ao dispositivo.

Scope Breakpoints: Mudanças no escopo do projeto. Cortar aquela feature que só afeta 2% dos usuários para o próximo release.

Feasibility Breakpoints: Mudanças nos detalhes técnicos. Usar um componente existente ao invés de criar algo custom.

Value Breakpoints: Mudanças no que e quando entregar. Refocalizar no caso de uso principal ao invés de perder tempo em áreas de baixo uso.

Escopo é o que cabe. Viabilidade é o que é possível. Valor é o que importa mais.

📡 Pilar 3: Revisão de Projetos

Software é contínuo. Uma busca infinita por melhoria contínua. Depois de completar a Entrega, você entra na fase de Revisão.

Drew aplica os mesmos princípios que usa para suas revisões semanais:

Wins: O que deu certo? O que você entregou?

Learnings: O que mudou? O que você aprendeu?

Takeaways: O que vem depois? Como melhorar?

Crie um Resumo dos Resultados detalhando tudo que foi entregue, o que mudou, e o que você está trabalhando em seguida. Mantenha simples, repetível e consistente para cada projeto.

Aprender em Movimento

Essa é a vantagem competitiva real.

Drew prefere aprender fazendo. Trial by fire. Quando cria um novo processo, constrói em movimento, captura feedback e itera em tempo real.

O Motor de Projetos é uma nova forma de trabalhar que:

• Substitui frameworks rígidos por intuição coletiva

• Substitui hand-offs desajeitados por integração profunda

• Substitui cerimônia infinita por iteração rápida

Você não perde tempo com simulações, suposições e predições. Faz o trabalho, como time, e move da concepção à criação com velocidade.

🌊 A Realidade Final

Todo planejamento é simulação até chegar ao usuário real.

Drew conta que, logo após lançar uma atualização de produto, encontrou vários bugs pequenos. A atualização tinha cobertura de testes, QA completo e uso em ambiente de staging. Ainda assim, problemas apareceram. Um deles só podia ser replicado em produção — relacionado a uma configuração de build que só acontecia no site ao vivo.

Tudo antes de usuários reais usarem seu produto em ambiente real é simulação.

Você escreve testes, cria processos de QA, deixa o time e clientes selecionados usarem para dar feedback. Mas, de alguma forma, coisas ainda escapam. Software é complexo. Variáveis demais. Navegadores diferentes, dispositivos diferentes, tamanhos de tela diferentes, velocidades de internet diferentes.

O melhor sistema não elimina essa complexidade.

O melhor sistema te leva mais rápido ao feedback real.

Limite o escopo. Teste com usuários reais. Teste no ambiente ao vivo.

Porque confiança é conquistada respondendo incógnitas, validando suposições e mitigando riscos — no mundo real, não na simulação.

📚 Conteúdos Recomendados

📄 Artigo: Project Engine — Drew Barontini - O artigo completo que inspirou esta newsletter, com detalhes sobre cada fase do motor.

📄 Artigo: Delivery Confidence — Drew Barontini - Como entregar software com confiança através de Scope Compression, Proxy Progression e Reality Immersion.

📖 Livro: Shape Up — Basecamp - A metodologia que inspirou o conceito de appetite/Time Budget e a ideia de fixar tempo e variar escopo.

Forte abraço,

Equipe Olympus